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THEME 


This  symposium  was  designed  to  explore  how  today’s  system  designer  i«  addressing  the  solution  to  tomorrow's  avionics 
systems  design. 

As  government  budgets  become  more  limited  for  the  research,  development,  testing  and  production  of  military  aircraft 
systems,  and  the  Warsaw  Pact  nations  continue  to  produce  all  types  of  aircraft  in  greater  numbers,  the  N  ATO 
look”  at  how  avionJ^  a-*.  .!e\  wIopwd.  lu  J,  me  avionics  community  has  thought  of  avionic  architecture  as  the 

integration  of  a  collection  of  "black  boxes”  (sensors,  navigation,  communication,  displays,  etc.)  with  the  software  allowing  for 
the  communication  between  “black  boxes”,  computers  and  man.  Normally,  the  system  is  decomposed  into  manageable  parts 
with  accurately  detined  interfaces.  By  rigidly  controlling  this  process,  aerospace  companies  have  developed  excellent  avionics 
systems  which  are  fully  integrated  into  aircraft  systems,  but  the  cost  is  high.  Cost  means  that  the  aircraft  is  required  to  perform 
multi'missions  which  often  lead  to  performance  compromises.  With  the  advent  of  the  VHSIC.  distributed  processing,  artificial 
intelligence,  sensor  data  fusion,  etc.,  the  technologists  are  blurring  the  clear  functional  allocation  defined  for  the  "black  box”. 
These  factors,  technology  and  cost,  provide  both  an  opportunity  and  a  challenge  to  the  system  designers  to  design  future 
avionics  systems  whose  performance  degrades  gracefully,  is  reliable,  and  is  affordable. 


Ce  Symposium  avail  pour  theme  les  meihodes  utilisces  aujourd’hui  par  un  conceptcur  dc  sysieme  pour  irouver  une 
solution  aux  problemes  poses  par  les  systemes  avioniques  de  demain. 

Comme  les  gouvemements  limitent  de  plus  en  plus  les  budgets  consacres  a  la  recherche,  au  developpement.  aux  essais  et  a 
la  production  des  systemes  d'avions  militaires  et  comme  les  pays  du  Pact  de  Varsovie  produisem  de  plus  en  plus  d'avions,  les 
pays  de  I’OTAN  doivent  reconsiderer  les  methodes  de  developpement  des  systemes  avioniques.  D'une  maniere  generale. 
I'industrie  avionique  considere  Tarchitecture  d'une  systeme  avionique  comme  un  ensemble  de  “boites  noires”  (detectenr*., 
navigation,  communication,  afflehage,  et...),  le  systeme  se  d^ompose  en  elements  pouvant  etre  geres  et  ayant  des  interfaces 
definies  avec  precision.  Par  une  maitrise  stricte  de  ce  processus,  les  societes  aerospatiales  ont  developpe  d'excellents  systemes 
avioniques  qui  sont  totalement  integrw  dans  les  systemes  de  I'avion,  mais  dont  le  cout  est  eleve.  Pour  des  raisons  de  cout. 
I’avion  doit  pouvoir  effecteur  des  missions  multiples,  ce  qui  nece^site  des  compromis  enire  les  performances.  Avec  Tapparition 
des  circuits  integres  ^  trw  grande  cchelle  (VHSIC),  de  r'mteUtgence  artificiclle,  de  la  fusion  des  donnees  de  detecteur,  etc...,  les 
technologies  brouillent  Timage  claire  que  Ton  avail  de  Taffectation  fonctionnelle  definie  pour  la  boite  noire.  Ces  facteurs 
techniques  et  economiques  offrent  une  occasion  ct  un  defi  a  relever  pour  les  conccpieurs  de  systeme;  ceux-ci  doivent  concevoir 
les  futurs  systemes  avioniques  dont  le  cout  et  la  fiabilite  doivent  etre  saiisfaisants  et  dont  les  performances  ne  doivent  se 
degrader  que  lentement. 
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SUMMARY 

The  overall  quality  of  the  papers  presented  at  the  symposium  was  first  class,  and  the  presentations  were, 
on  the  whole,  excellent.  However,  the  relevance  of  the  subject  matter  to  the  stated  topic  of  a  session  was 
weak  in  several  cases.  Although  these  papers  addressed  the  primary  topics  in  the  broadest  sense,  their 
subject  matter  was  often  unfocused  and  diffused.  Their  primary  point  was  usually  a  reiteration  of  how' 
avionic  system  design,  development,  and  test  was  accomplished  on  a  specific  project.  It  would  have  been 
better  if  these  papers  clearly  stated  the  problem  and  how  it  was  solved.  If  we  in  iheavionics  community  had 
more  standardized  ways  of  doing  business,  we  would  most  likely  face  the  same  problems,  and  any  discussion 
on  their  resolution  would  certainly  draw  our  attention. 

The  symposium  clearly  emphasized  two  vital  requirements  in  the  development  of  avionic  systems; 

•  Current  and  future  avionic  systems  are  so  complex  and  require  such  a  diversity  of  talents,  expertise, 
and  resources  to  design,  develop,  and  test  that  a  stringent,  rigorous,  methodical  top-down  approach 
using  the  latest  computer-aided  technique:^  must  be  applied. 

•  Standards  are  needed  in  almost  every  area. 

Without  some  sort  of  agreement  and  implementation  of  standards  to  impose  discipline,  future 
symposia  will  repeat  the  theme  of  this  one:  “Here  is  how  1  did  it.  now  show  me  how  you  did  it.'*  While 
exploring  different  approaches  and  sharing  lessons  learned  are  beneficial,  more  progress  could  be  made  b> 
nt  '■«»-eping  to  vse  th*.  •  npproac^e^  *cchi>irue«  etc.,  and  evaluating  our  successes,  failures,  and 
problems  when  the  next  symposium  is  convened. 

THEME  AND  OBJECTIVES 

The  title  of  this  symposium  was  "The  Design.  Development,  and  Testing  of  Complex  Avionics 
Systems.”  However,  this  title  barely  does  justice  to  the  subject.  In  the  recent  past,  a  near  revolution  has 
occurred  in  avionic  system  requirements,  including  howtheyare  built  and.  as  was  continuously  emphasized 
in  the  presCiiUlions,  how  they  are  operated. 

The  stated  theme  was  “to  explore  how  today's  system  designer  is  addressing  the  solution  to  tomorrow  N 
avionics  system  design.”  The  presentations  adequately  addressed  this  theme  with  descriptions  of  current 
and  near-future  efforts,  all  with  forward-looking  implications. 

It  was  clear  from  the  content  of  the  presentations  that  ail  member  countries,  as  well  as  the  companies 
within  those  countries,  arc  experiencing  (he  same  problems  in  designing  advanced  avionic  systems.  What  is 
truly  remarkable  is  the  virtual  unanimity  in  the  approach  to  resolving  the  problems. 

The  symposium's  goal  was  to  share  the  experiences,  successes,  and  pitfalls  surrounding  this  complex 
subject  and  to  take  advantage  of  lessons  learned.  Judging  from  the  size  of  the  audience  at  each  session,  the 
session,  the  enthusiastic  question  and  answer  periods  following  each  preseniation.  and  the  variety  of 
experiences  discussed,  (he  symposium  may  be  considered  a  resounding  success. 

TECHNICAf-  CONTENT 

The  symposium  began  with  an  opening  address  by  VAUM  G.  Clarke.  Commander  of  the  Space  and 
Naval  Warfare  (SPA  WAR)  Systems  Command  of  the  United  States  Navy.  He  set  the  tone  for  the  rr.tetmg 
by  strongly  emphasizing  the  need  for  system  designers  to  consider  the  whole  system  in  the  design  process 
rather  than  the  avionics  portion  only.  According  to  the  Admiral,  the  whole  system  includes  surface  ships, 
aircraft,  submarines,  space  vehicles,  and,  most  importantly,  man.  Admiral  Clarke  then  described  his  task  as 
Commander  of  SPAWAR  to  establish  a  total  system  architecture  approach  to  the  battle  group  and  to  do  it 
top-down  for  the  first  time  ever.  He  described  the  process  he  and  his  staff  are  using  and  the  three  major 
components  of  the  architecture:  the  tactical  command  system,  the  communication  support  system,  and  the 
warfare  support  system. 


viii 


Admirai  Clarke’s  comments  were  reiterated  throughout  the  symposium.  His  emphasis  on  an  orderly . 
rigorous,  structured  top-down  approach  was  the  single  most  common  element  of  virtually  all  presentations 


Session  1  —  Design  Aspects  of  Future  Avionic  Systems 

In  Paper  No.  I.*  the  author  describes  a  cooperative  planning  cuuit  between  the  I'.S.  National 
Aeronautics  and  Space  Administration  (NASA)  and  the  Department  of  Defense  (DOD)  to  conduct  studies 
to  determine  technology  development  requirements  for  the  design  of  the  next  generation  of  space 
transportation  systems.  A  thorough  top-down  hierarchical  approach  being  used  on  this  project  is  described 
TTiis  approach  covers  major  categories  such  as  guidance,  navigation,  and  control;  flight  systems 
management;  system  integration;  and  modeling,  communications,  and  man  systems  interfaces.  Die 
multitude  ot  research  elements  that  must  be  considered  provides  ample  justification  for  using  a  structured, 
rigorous  approach.  The  paper  highlights  the  need  for  significant  systems  as  an  important  driving  faaot 
While  the  paper  addresses  only  one  of  five  major  phases  of  the  avionic  system  planning  process,  a 
systematic,  classical  approach  is  taken:  Define  the  potential  (generic)  mission,  define  the  (generic)  vehicle  to 
satisfy  the  mission,  and  identify  the  technology  needed  to  build  the  vehicle  The  time  frame  for  the  fi-st 
vehicle  is  post-2000. 

Paper  No.  2  calls  for  standardisation  at  vahouslevels  to  help  solve  the  problem  of  transitioning  today's 
architectures  into  architectures  of  the  future  without  having  to  start  from  the  beginning  As  the  author 
points  out,  we  never  start  with  a  totally  new  design,  but  one  that  is  almost  always  based  upon  an  existing 
design.  Therefore,  a  “bridging”  or  transitioning  technioue  must  be  developed.  He  identifies  two 
requirements  to  accomplish  this; 

•  A  doctrine  that  defines  both  future  architectures  and  the  intermediate  “transitional”  architectures 

•  An  inlerplatform  interface  requirements  document. 

The  author  proposes  to  develop  a  high-level  architecture  of  the  future  and  a  standard  method  to 
identify  the  components  and  structure  of  that  .?*’chiteciure.  He  also  calls  for  some  form  ofstandardiTatJon  or 
commonality  across  platforms,  and  even  across  national  boundaries,  a  view  that  was  expressed  by  many 
throughout  the  symposium. 

Paper  No.  3  highlights  the  role  of  sensors  in  a  hypothetical  future  aircraftandemphasizesihecomplex 
problems  facing  the  pilot.  These  aircraft  will  be  equipped  with  highly  capable  sensors  with  different  data 
rates,  ranges,  and  accuracies  that  sometimes  do  not  supply  data  (e  g.,  because  of  jamming).  The  analysis, 
reduction,  fusion,  correlation,  and  tracking  of  these  data  can  be  accomplished  in  a  decentralized,  adaptable 
system  with  the  aid  of  artificial  intelligence  (Al).  also  known  as  the  “pilot’s  associate. ’’The  auihoi  sutesihat 
the  successful  developer  of  the  future  will  be  the  one  that  best  manages  the  myriad  of  different  contractors 
(hat  will  be  required  to  design  and  integrate  such  a  system. 

Papers  Nos.  4  and  S  introduce  advanced  tools  to  aid  the  design  of  complex  systems.  Expert  Consultant 
for  Avionic  Systems  Transformation  Exploitation  (ECATE).  desenbed  in  Paper  No.  4.  is  an  expert  system 
that  aids  the  rapid  prototyping  of  avionic  systems.  Paper  No.  5  discusses  the  Controlled  Requirements 
Expression  (CORE)  system,  which  is  useful  in  providing  unambiguous  functional  descriptions  and 
representing  dynamic  interactions  within  and  across  systems.  The  use  of  sophisticated  tools  will  be 
mandatory  to  ensure  the  successful  cxe<''’»»on  of  current  and  future  complex  avionic  system  designs.  This 
issue  raises  two  questions: 

•  Will  the  ability  to  design  more  complex  systems  depend  on  the  ability  to  design  increasingly  complex 

tools? 

•  Can  tools  be  used  to  design  tools? 

Work  on  the  Experimental  Aircraft  Program  (EAP)  is  the  topic  of  Paper  No.  6.  The  author  describes 
the  use  of  the  CORE  tool  to  impose  a  top-down  structured  design  approach.  The  use  of  CORE  resulted  in 
the  remarkable  conclusion  that  after  20  flights  of  the  aircraft  in  the  first  1 8  days  of  flight,  no  system  changes 
were  deemed  necessary.  Apparently,  enforcing  a  superior,  strictly  followed  approach  can  lead  to 
outstanding  results.  This  raises  the  suspicion  that  many  problems  encountered  in  avionic  system  design 
projects  may  be  due  to  taking  shortcuts  and  known  high-risk  paths. 

Paper  No.  7  best  addresses  the  subject  of  the  first  session.  This  paper  describes  the  development  of  a 
^neric  architecture  of  the  future.  The  author  identifies  the  salient  characttiistics  of  the  future  system,  such 
as  distributed  processing  and  control  (not  shared  processing),  fault  tolerance  leading  to  uninterrupted 
operation,  and  stringent  real-time  performance  demanding  very  short  control  loops.  The  paper  also 
describes  a  very  practical,  professional  approach  taken  to  these  subjects  and  discusses  the  problems  of  real¬ 
time  processing.  The  author  also  calls  for  some  form  of  standardization  in  control/ data  distribution  to 
faciUttiti*  task  of  system  designers,  in  this  case  the  Society  of  Automotive  Engineers  (SAE). 


*A  lilt  of  the  complete  title  end  authors  of  each  paper  is  presented  at  the  end  of  ihh  paper. 
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The  use  of  special  test  '*rigs”  and  predefined  standard  interfaces  to  expedite  the  testing  of  the  EH- 10 1 
helicopter  integrated  avionic  suite  is  discussed  m  Paper  No.  8.  A  “rig”  is  actually  a  complex  system  in  itself, 
consisting  of  computers,  emulators,  simulators,  buses,  etc  .  that  allow  testing  to  proceed  without  the  delays 
associated  with  the  lack  of  some  system  components.  Again,  initial  planning  and  standardised  interlaces 
helped  the  system  designers  considerably  in  the  latter  development  stages. 

Paper  No  9  describes  the  use  of  the  formalized  System  Engineering  Technique  (SEI  ).  which  was 
developed  to  improve  both  the  quality  and  productivity  of  system  engineering  tasks.  Theauihorsemphasii’c 
that  no  tool,  technique,  or  methodology  will  replace  common  sense,  and  that  S£1  is  not  really  new,  but  a 
formalization  and  integration  of  existing  procedures  and  worksheets.  I'he  authors  describe  the  use  ol  three 
models: 

•  A  functional  model  that  outputs  requirements. 

•  A  physical  model  that  is  represented  by  the  design. 

•  An  operational  model  used  for  final  system  analysis. 

These  models  should  lead  lospecific  quantifiable  constraintsandsystem  components.  ITiis  particular  paper 
generated  much  interest  among  the  symposium  attendees,  as  evidenced  by  the  large  number  ol  pertinent 
questions. 

As  described  m  Paper  No  10.  a  rigorous,  strictly  adhered  to  methodology  was  responsible  lor  the 
successful  development  of  the  RAFALE  aircraft.  Rapid  prototyping  of  complex  systems  was  also 
beneficial.  This  technique  improved  the  quality  of  the  functional  design  specifications,  which,  as  the  author 
points  out.  are  the  cornerstones  of  the  whole  effr*-!.  Rapid  prototyping  was  used  to  validate  the  functional 
specifications  that  were  prepaicd  by  adhering  to  a  ngid  top-down  methodology  As  a  result  of  these 
procedures,  a  first  flight  was  conducted  six  months  ahead  of  schedule,  and  the  number  of  errors  m  the 
specifications  was  greatly  reduced. 

Paper  No.  1 1  is  a  thoughtful  presentation  on  the  impact  of  software  on  avionic  architecture.  A  bnci 
review  o(  avionic  system  development  history  shows  that  technology,  as  a  whole,  has  grown  exponentially, 
with  hardware  following  in  a  very  similar  manner.  However,  software  capabiliiies  and  man's  ability  to 
pioduce  It  have,  unfortunately,  not  followed  suit.  Ycl.  software  will  be  the  main  constraint  in  satisfying 
future  requirements;  no  alternatives  arc  foreseen.  A  new  model  was  proposed,  wherein  the  rework  required 
after  an  error  is  found  will  be  limited  to  a  small  step  backward  m  lime  rather  than  the  large  rework  loop  that 
is  used  on  most  of  today's  efforts,  I  he  author  feels  that  careful  definition  of  information  flows  early  m  the 
design  process  is  the  key. 

The  12th  paper  listed  on  the  agenda  svas  not  presented  at  the  symposium. 

In  Paper  No.  13.  the  author  compares  integrated  and  separate  systems  for  flight  control  and 
navigation.  The  main  problem  is  that  the  two  subsystems  have  somewhat  divergent  characteristics.  The 
problems  of  vibration,  data  processing,  and  increased  vulnerability  as  a  result  of  separating  the  systems  are 
discussed.  The  author  concludes  that  the  integration  of  flight  control  sensors  and  the  inertial  navigation 
system  (INS)  m  one  system  is  basically  feasible  and  has  been  successfully  implemented. 

Paper  No.  14  emphasizes  that  while  new  technologies  provide  designers  with  all  sorts  of  new 
opporlunilies,  (hey  are  also  posing  significant  challenges.  The  sheer  complexity  of  the  proposed  systems 
demands  that  a  stringent,  predictive,  analytical  methodology  be  employed.  Further,  the  role  of  man  in  the 
system  must  be  given  (he  attention  it  is  due.  The  author  believes  that  mams,  after  a II.  at  least  as  important  a 
component  as,  for  example,  a  radar  Man’s  performance  in  the  system  should  be  analyzed  in  as  much  detail 
as  the  system  hardware.  The  paper  describes  an  approach  that  encompasses  mission  functional 
requirements  analysts,  candidate  system  development  and  gross  task  analysis,  critical  task  analysis,  system 
performance  analysis,  and  validation.  Again,  a  rigorous,  analytical  top-down  approach  seems  to  be  the  key 
to  success. 

In  paper  No.  IS,  the  authors  discuss  'he  use  of  a  formalized,  structured  methodology  called 
“Crewstation  Information  and  Development  System”  (CIDS).  The  importance  of  specific  requirements 
that  stand  on  their  own  merit  is  stressed,  and  they  arc  used  throughout  CIDS.  CIDS  provides  a  quantified 
method  for  making  critical  design  decisions,  and.  therefore,  is  suitable  for  partial  or  complete  automation. 
As  a  result  of  using  CIDS.  the  design  can  be  considered  optimal  in  accordance  with  the  parameters  and 
weighting  factors  chosen  by  the  designers.  The  system  provides  requirements  traceability,  degraded  mode 
handling,  redundancy  handling,  and  strict  interface  designs.  A  concept  demons  iration  of  CIDS  is  due  in  the 
fourth  quarter  of  1987. 

Paper  No.  16,  delivered  by  R.  DeSipio.addressestheroleof  manin  the  system.  The  increase  in  raw  data 
to  the  human  in  the  system  will  overload  him.  Data  must  be  converted  into  processed  information  before 
they  are  presented  to  the  human  for  decision  making.  Even  the  decision-making  process  should  be 
augmented  by  knowledge-based  systems,  if  he  is  to  devote  the  majority  of  his  attention  to  the  tactical 
situation.  The  authors  propose  a  reorientation  of  the  system  design  process,  in  which  the  design  is  based 


upon  decision  requirements  rather  than  hardware  performance.  It  appears  that  the  mure  complex  the 
system,  the  harder  the  job  for  the  man  m  the  loop.  Or,  as  one  participant  put  it.  "‘high  technology  equals  high 
uorkload.” 

Session  2  —  Managing  the  Future  System  Design  Process 

In  the  first  paper  of  the  second  session.  Paper  No.  17.  the  author  addresses  a  tool  that  Northrop  use.s  as 
an  aid  in  managing  avionic  system  design.  The  Avionic  S>-stcm  Enginecnng  Tool  (ASET)  automates  the 
cornpany’s  itruciured  design  approach,  which  comprises  four  phases: 

•  Abstract  requirements  identification. 

•  Requirements  and  functional  decomposition. 

•  functional  recomposition. 

•  Detailed  interface  and  bus  definition. 

ASET  was  designed  to  help  diseminate  information:  be  expandable,  maintainable,  fast,  powerful,  and 
user-friendly;  require  only  a  short  learning  curve;  produce  hard  copy;  and  handle  classified  data.  As 
overwhelming  as  these  requirements  appear,  the  author  '  laims  that  ASEl  meets  them.  Further,  it  provides 
traceability,  modification  time  decreases,  I  ONerificaiion.  throughput  and  memory  analyses,  and  improved 
software  designs  and  test. 

Paper  No.  18  addresses  issues  concerning  the  human  in  the  cockpit,  ergonomics,  and  the  use  of  Al.  The 
authors  describe  two  expenments  under  way  in  the  laboratory,  one  dealing  with  vision  and  imaging,  the 
other  with  cognitive  psychology  and  cognitive  aids  in  cockpits.  To  date.  database.s  have  been  produced  on 
the  iransler  functions  of  vision  and  the  results  of  peripheral  vision  studies.  These  databases  have  been  used 
111  developing  models  of  vision  to  aid  interpretation  of  complex  images.  The  process  is  now  being  used  to 
interpret  satellite  image  data.  This  knowledge  will  aid  pilots  under  stresses  of  acceleration  and  vibration  and 
reduce  the  effects  of  hypoxia. 

The  objective  of  the  second  experiment,  which  involves  cognitive  psychology,  is  to  assess  the  use  of  Al. 
working  in  concert  with  the  pilot  in  real-time,  to  provide  an  analysis  of  the  pilot's  current  situation.  The 
"context  detection  unit"  is  especially  interesting  and  appears  to  be  a  rather  advanced  application  of  Al. 

Paper  No  19  presents  an  approach  to  automated  cockpit  design  with  a  tool  called  "Cockpit 
Automation  Design  Support  System"  (CADSS).  The  authors  identify  a  number  of  deficiencies  associated 
with  today’s  way  of  doing  business,  including  lack  of  standardization,  dependence  on  people  s  unique 
abilities,  manual  procedures,  outdated  design  guides,  and  poor  change  management.  While  the  approach 
taken  by  these  authors  is  similar  to  others  described  at  the  symposium.  CADSS  is  uniquely  tailored  for  and 
applteo  to  cockpits.  Competing  teams  are  building  CADSS  now.  and  demonstrations  arc  scheduled  for 
May  1988. 

The  fourth  paper  of  this  session.  Paper  No.  20,  describes  a  system  for  search  and  rescue  on  a  helicopter. 
The  paper  identifies  the  eight-leg  mission  used  as  a  scenario  and  the  three  subsystems  constituting  the 
architecture:  the  display,  the  autopilot,  navigation  subsystem,  and  mission  management  subsystem.  A 
detailed  technical  explanation  of  the  navigation  and  mission  management  subsystems  revealed  a  complex, 
capable  equipment  suite.  The  Nadir  Mk2  computer,  for  example,  is  a  32-bil  microprogrammable  system 
that  can  execute  al  a  rate  of  1  MOPS.  The  system  was  specifically  designed  for  the  type  of  real-time 
operations  needed  for  this  project.  The  development  effort  required  3  1 ;  2  years  to  complete  (7  months  for 
definition),  and  the  first  flight  occurred  in  18  months.  Software  development  was  performed  on  a  VAX  785 
and  a  MICROVAX,  with  the  aid  of  microprocessor  emulators. 

The  authors  describe  a  complex  interactive  relationship  that  exists  between  the  system 
designers,  integrators  and  the  equipment  manufacturers.  High  rates  of  information  flow  between  the  two 
groups,  and  complementary  tools  aid  successful  interaction.  This  aspect  of  system  design  was  not  touched 
upon  in  other  papers,  but  it  is  certainly  worthy  of  further  consideration. 

In  Paper  No.  21,  the  author  effectively  justifies  the  need  for  high  levels  of  automation  and  fully 
integrated  architectures  with  powerful  central  processing  ca^biiity.  His  description  of  a  helicopter 
communication  system  and  the  concerns  faced  by  system  designers  in  building  the  system  highlight  some  of 
today’s  problems.  Nap-of-thc-canh  communication,  target  data  handoffs,  auto  reconfiguration  upon 
failure,  and  operations  in  the  presence  of  intense  Jamming  are  enough  to  convince  even  the  most  skeptical 
that  ad  hoc  methods  are  grossly  outdated. 

Paper  No.  22  focuses  on  one  of  the  main  problems  addressed  at  this  symposium;  (hat  is.  (he  design  of 
crew  system^  has  typically  involved  little  systematic  con.vidcration  of  human  performance  characteristics 
and  limitations.  The  author  describes  an  Air  Force  thrust  to  manage  design  information,  namely  the 
Integrated  Perceptual  Information  for  Designers  (IPID)  Project.  The  goal  of  the  IPID  Project  is  to 
consolidate  human  performance  data,  present  these  data  in  useful  formats,  train  designers  in  the  use  of  the 
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data,  and  make  the  data  accessible.  Descriptions  are  provided  on  how  the  project  personnel  intend  to  meet 
the  goals  of  the  IPID  Project.  It  seems  obvious  that  some  approach,  such  as  the  one  described  in  the  paper, 
must  be  used  if  the  more-or-less  heuristic  approach  to  design  is  to  become  more  scientific. 


In  Paper  No.  23,  the  author  describes  a  projcc:  to  produce  interchangeable  modules  (hardware) 
manufactured  by  two  different  contractors.  The  statement  of  work  mandated  the  exchange  of  modules  of 
equivalent  function  without  any  impact  on  software.  The  MIL-STD-1750A  computer  was  produced  out  of 
a  VAMP  module  set.  The  illustrations  show  that  two  very  dissimilar-looking  modules  are  actually 
replacements  for  each  other.  At  the  end  of  the  project,  interoperability  will  be  demonstrated.  Tlte  author 
also  declares  that  the  biggest  problem  associated  with  using  standard  hardware  is  the  software  and  predicted 
this  problem  will  become  worse. 

Paper  No.  24  describes  the  problems  electromagnetic  fields  cause  modern  electronic  devices.  All  the 
characteristics  that  are  inherent  to  modern  high-technology  devices,  such  as  the  change  from  black  boxes  to 
integrated  devices,  the  use  of  low-voltage  circuitry,  and  the  use  of  VHSIC-sized  components,  make  it  easier 
for  stray,  unwanted  electromagnetic  fields  to  upset  the  state  of  the  devices.  The  author  calls  for  guidelines  in 
many  areas,  including  grounding,  bonding,  filtering,  shielding,  electrical  interfaces,  etc.  Further,  to  be 
useful  in  practical  applications,  these  guidelines  must  be  specific,  applications,  not  generic  “motherhood” 
statements.  Testing  also  needs  improvement.  In  accordance  with  MIL-STD-461/  462A/  B,  current  methods 
imply  stand-alone  equipment  designs,  not  full  systems,  in  addition,  susceptibility  criteria  are  not  clearly 
defined. 

The  integration  and  testing  of  an  airborne  radar  is  discussed  in  Paper  No.  25.  This  paper  provides  some 
unassailable  advice:  An  informed,  fundamental,  and  methodical  approach  is  needed:  software  integration  is 
important;  tests  must  be  performed  on  the  actual  radar  and  not  only  on  the  simulator;  and  an  acceptance 
test  may  be  required  for  the  sponsor.  While  most  of  the  material  presented  is  commonly  accepted,  some  of 
the 


The  final  paper  of  this  session.  Paper  No.  26,  describes  expected  developments  in  microelectronics 
technology  in  the  next  10  to  1 5  years.  The  author  points  out  that  in  the  last  20  years,  microelectronic  devices 
have  increased  200  percent  in  density  and  20  percent  in  speed.  The  future  will  probably  bring  CMOS,  io^er 
power  consumption,  higher  densities,  and  submicron  dimension.  By  the  year  2(X)0. 0.3-micron  feature  sizes 
will  be  possible.  The  author  also  explains  different  kinds  of  IC  processingand  technologies  and  declares  that 
perhaps  the  best  of  two  worlds  might  be  achieved  by  a  BIMOS  technology  (e  g.,  CMOS/  BIPOLAR).  The 
message  of  this  paper  is  to  expect  rapid  advances,  including  some  that  were  thought  impossible  just  a  few 
years  ago,  and  more  computer  tools. 

Session  3  -  System  Design  Tools  and  Integration 

In  the  first  paper  of  the  third  session.  Paper  No.  27.  the  author  uses  convincing  historical  data  from  1 0 
projects  over  the  last  12  to  (3  years  to  show  that  the  projects  that  used  consistent  and  m-depih  human 
engineering  processes  had  the  fewest  design  changes.  One  of  the  points  made  in  this  paper  was  voiced  earlier 
in  the  symposium  at  least  twice:  Look  ahead,  perceive  how  equipment  will  be  used  in  conjunction  w  itK  the 
human  being,  and  design  functionality  into  the  equipment. 

Large-scale  software  development  and  testing  are  the  focus  of  Paper  No.  28.  The  most  advanced,  state- 
of-the-art  tools,  approaches,  and  methodologies  are  described.  A  typical  cross-development  is  described. 
The  software  validation  rack  provides  environmental  simulation,  graphic  output,  and  various  operational 
modes.  The  author  identifies  a  trend  that  can  (^readily  perceived;  Froni-cnd  tools  (eg.  specification  tools) 
will  be  integrated  with  back-end  tools  (c.g.,  test  tools).  A  natural  progression  from  specification  tool,  to 
semiformal  specification,  to  prototype,  to  stimuli,  to  test  tool  is  foreseen.  The  potential  for  massive 
automation  of  the  process  seems  obvious. 

Paper  No.  29  describes  the  use  of  CAD/ CAM  technology  as  it  can  be  applied  to  the  system  design 
process. 

In  Paper  No,  30,  the  author  descries  current  design  automation  systems'  almost  total  lack  of  ability  to 
capture  and  communicate  the  context  within  which  a  design  is  developed.  He  points  out  that  current 
standardization  efforts  focus  on  syntax,  do  not  separate  “what”  from  “how,”  and  use  ad  hoc  semantics, 
among  other  faults.  He  describes  a  process  called  “Abstract  Resource  Design  Methodology,”  which  may 
have  the  potential  to  correct  many  of  the  stated  deficiencies.  These  complaints  are  valid,  although  the 
impact  of  the  deficiencies  on  the  concept-design-implementation  process  is  not  obvious. 

Paper  No.  31  describes  how  the  Avionics  System  Test  Training  Aircraft  (ASTTA)can  be  beneficial  in 
the  design  process.  Because  designers  have  limited  viewpoints  about  the  operational  environment  and 
testers  generally  lack  avionic  system  test  training,  the  resulting  system  can  often  overtax  and  overwhelm 
system  users.  A  flying  test  bed  employed  early  in  the  process  can  alleviate  some  of  these  problems.  The 
audience  tended  to  challenge  the  concept's  nonreal-time  operation  and  its  less  than  100-pcrcent  system 
fidelity.  The  question  of  cost-effectiveness  was  also  raised. 


Paper  No.  32  addresses  a  modem,  high-powered  approach  to  software  engineering  used  by  British 
Aerospace  (BAE)  on  the  Experimental  Aircraft  Program  (EAP).  Modern  tools,  such  as  CORE, 
PERSPECTIVE,  and  DASS,  and  capable  host  computers  (i.e.,  VAXs)  were  used  in  concert  with  sound 
engineering  practices  (e.g.,  thread  diagrams,  automated  documentation,  etc.)  to  increase  productivity  and 
reduce  errors.  The  author  quotes  figures  of  a  five-fold  increase  in  productivity  and  a  five-fold  reduaion  of 
errors  (from  10  to  2  errors  per  1 ,000  LOC).  Again,  the  author  notes  a  trend  toward  true  integration  of  tools 
and  methodologies. 

Paper  No.  33  discusses  the  development  of  a  set  of  automated  tools  to  aid  in  the  design  of  avionic 
systems,  from  the  definition  phase  through  the  software  production  phase.  (The  tools  are  actually  described 
in  some  detail  in  Paper  No,  36,  which  was  presented  immediately  following  this  paper.)  The  author  describes 
the  by-now  familiar  cluiracicrislics  of  the  systems  we  arc  concerned  with:  highly  integrated,  open-ended, 
and  safe.  The  major  problems  in  designing  such  a  system  successfully  (i.e.,  one  that  meets  requirements 
within  budget  and  on  time)  are  cost/schedule  control,  communications  between  the  different  contractors, 
validation  of  the  system,  and  management  of  the  massive  amount  of  documentation  that  is  produced.  A 
thorough  description  of  the  steps  involved  in  the  various  design  phases  is  also  provided  in  this  paper. 

A  software  life-cycle  environment  being  built  for  the  Rome  Air  Development  Center  is  discussed  in 
Paper  No.  34.  This  VAX-based,  multilingual  (JOVIAL,  FORTRAN,  Ada,  COBOL),  multirole,  distributed 
facility  covers  the  full  software  life  cycle.  The  authors  point  out  that  32  tools  will  provide  users  with  basic 
capabilities  in  requirements  definition,  design,  prototyping,  coding,  test,  verification,  project  management, 
configuration  management,  environment  management,  etc.  Full  functional  capability  is  scheduled  for 
August  1988.  The  audience  questioned  the  portability  of  tools  developed  for  a  virtual  memory  system 
(VMS). 

Paper  No.  35  describes  a  system  to  be  installed  in  a  research  aircraft  that  comprises  1 1  subsystems.  The 
system  will  be  used  to  help  solve  the  problems  of  aircraft  routing  caused  by  increased  air  traffic  that  must  be 
handled  by  a  constant  number  of  airports.  The  author  believes  that  new  avionic  systems  (e.g..  microwave 
landing  systems.  Global  Positioning  System, electronic  flight  instrument  systems,  etc.)  can  help  alleviate  the 
situation  if  properly  used.  The  research  aircraft  will  be  used  as  a  tool  and  should  be  finished  by  the  end  of 
1999. 

Paper  No.  36  is  a  “companion”  paper  to  Paper  No.  33,  both  of  which  were  presented  in  the  third 
session.  In  this  paper,  the  authors  expand  upon  theavionicdevelopmeni  system  that  was  described  in  Paper 
No.  33.  The  authors  explain  that  this  concept,  developed  by/ for  the  French  avionic  community,  resulted  in 
an  open-ended  suite  of  integrated  tools  that  is  useful  in  system  design  and  software  development.  Each 
participating  contractor  may  add  on  or  tailor  the  basic  too)  set  to  his  individual  requirements.  The  authors 
describe  a  “hosting  structure”  tool  (hat  ties  the  whole  system  together  and  three  other  basic  tools;  CXTS,  a 
system  design  aid;  DLAO,  a  computer-aided  software  definition  tool;  and  SAO,  a  graphic,  detailed 
specification  language. 

The  authors  also  indicate  that  some  of  the  tools  developed  have  already  been  used  on  some  recent 
French  projects,  and  that  the  workshop  concept,  supported  in  part  by  the  French  Ministry  of  Defense,  was 
successful  in  aiding  the  definition  of  complex  avionic  systems,  the  production  of  better  specifications,  and. 
perhaps  most  significantly,  the  communications  between  the  various  entities  involved  in  the  effort. 

A  “coherent”  functional  development  methodology  is  the  focus  of  Paper  No.  37,  This  concept  was 
developed  over  tiic  past  five  years  and  is  used  by  Rockwell  Aviation.  The  term  “coherent”  identifies  the  need 
to  take  into  account  the  interactions  of  the  real  system,  on  a  time-line  basis,  to  produce  an  effective, 
workable  system.  The  technique  and  tools  to  develop  such  a  system  are  embodied  in  a  methodology  called 
“Coherent  Design  Evaluation  Simulation"  (CODES),  which  is  used  to  produce  high-quality,  real-time, 
man-in-the-loop  simulations.  The  tool  couples  the  man  with  avionic,  vehicle,  and  flight  control  models  and 
imposes  a  time-line  scenario.  The  power,  complexity,  and  sophistication  of  CODES  are  evident  from  its 
statistics:  hosted  on  two  Harris  1,200  CPUs  plus  ADI-IOO,  contains  about  lOOK  SLOC  in  FORTRAN,  and 
uses  an  Evans  and  Southerland  CT-6  graphics  system. 

The  value  of  a  device  such  as  CODES  to  an  aerospace  manufacturer  is  obvious.  Although  the  cost  is 
high,  it  is  a  bargain  when  compared  with  less  effective  options.  The  deficiencies  of  current  development 
methods  are  real.  Resolving  them  requires  determination  and  commitment. 

RECOMMENDATIONS 

Although  it  is  difficult  to  determine  the  technical  content  of  a  proposed  paper  from  an  abstract,  more 
effort  should  be  expended  to  avoid  duplicating  the  very  similar  nature  of  many  papers.  It  must  be  frustrating 
for  a  speaker  scheduled  late  in  the  day  to  hear  his/her  key  points  and  ideas  expounded  upon  three  or  four 
times  before  he/she  has  a  chance  to  speak. 

It  would  also  be  helpful  to  symposium  attendees  if  a  hard  copy  of  the  transparencies  used  during  the 
presentations  were  made  available.  These  transparencies  often  have  very  dif^ferent  content  from  the 
published  paper  and  synopsize  the  paper  very  well. 


Since  software  development  is  a  major  part  of  the  development  of  avionic  systems,  perhaps  a  special 
conference  should  be  dedicated  solely  to  sohware  tools,  techniques,  and  environments. 

The  symposium  included  extensive  discussion  of  tools  and  programs  to  aid  development  activities.  It 
would  have  Imn  helpful  if  actual  examples  of  tool  outputs  were  shown. 

Finally,  although  it  is  admittedly  not  a  function  of  AGARD,  some  effort  to  influence  or  even  effect 
standardization  should  be  seriously  considered  by  the  executive  committee. 
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KEYNOTE  ADDRESS 
TO 

53RD  PANEL  MEETING/SYMPOSILM 
OF  THE 

AVIONICS  PANEL 
NATO-AGARD 
las  Veffts,  Nevada 
27  April  1987 

Vice  Admiral  GIcnwood  Clark,  USN 
Commander,  Space  and  Naval  Warfare  Syttems  Command 


On  behalf  of  the  United  States  Government  and  the  Department  of  Defense.  1  would  like  to  welcome 
you  to  our  country;  Las  Vegas,  Nevada;  and  to  the  S3rd  Panel  Meeting/ Symposium  of  the  NATO-AGARD 
Avionics  Panel.  It  is  a  pleasure  for  me  to  be  your  keynote  speaker  and  to  address  such  a  distinguished 
gathering. 

These  meetings  are  an  important  element  of  the  technology  activities  of  NATO,  giving  us  the 
opportunity  to  review  the  quality  work  that  is  under  way  within  the  allied  countries  of  NATO.  Theyoffera 
chance,  from  time  to  time,  to  establish  and  renew  the  persona)  contact  between  colleagues  doing  similar 
work.  The  close  proximity  of  Nellis  Air  Force  Base  gives  us  the  unique  opportunity  to  see  firsthand  the 
tactical  implications  of  our  research  and  development  work. 

This  group  has  set  a  very  ambitious  and  vital  task  for  itself  when  it  explores  how  the  system  designer 
will  build  tomorrow's  integrated  avionics  systems.  As  a  senior  military  officer  and  a  former  program 
manager,  I  know  we  have  successfully  met  the  challenge  of  today's  threats  by  developing  and  building 
quality  systems.  But,  I  am  concerned  about  how  we  will  meet  the  challenge  of  future  threats,  with  the  new 
technology  and  systems  currently  in  development. 

The  papers  to  be  presented  here  and  the  ensuing  discussions  will  begin  to  chart  a  course  through  this 
new  territory.  It  is  easy  to  see  that  you  are  on  urget  with  the  subjects  like  rapid  prototyping,  sensor  fusion. 
Ada,  multiaperture  seekers,  very  high-speed  integrated  circuits,  artificial  intelligence,  and  generic 
architectures  that  are  essential  to  the  development  of  a  new  generation  of  systems.  However,  we  must  be 
sensitive  to  the  implications  of  the  toul  system. 

I  was  pleased  to  accept  an  invitation  to  give  this  keynote  address  because  in  my  current  job  as 
Commander,  Space  and  Naval  Warfare  Systems  Command  {SPA  WAR),  I  am  fully  involved  with  this  issue. 
The  total  system,  in  its  broadest,  most  generic  sense,  involves  air.  land,  sea,  and  space-based  sensors.  It 
involves  sea,  land,  and  air  forces  working  in  concert  as  an  integrated  network  or  system.  This  is  what  1  mean 
by  the  total  system. 

We  face  a  potential  enemy  today  that  can  field  vastly  superior  number.  Our  strategy  will  be  the  use  of 
superior  technology  combined  with  the  ability  to  network  our  activities.  We  have  the  capability  now,  as 
never  before  possible  in  history,  to  integrate  and  focus  our  fighting  forces  into  the  ultimate  total  system. 

For  example,  in  a  "war-at-sea "scenario,  w«  expect  some  time  in  the  near  future  to  form  a  computer 
network  of  fleet  air  defense  multipurpose  fighter/ attack  aircraft,  picket  ships,  and  long-range  surveillance 
aircraft  which  can  share  control  of  long-range  missiles  far  beyo^  visual  range. 

The  degree  of  information  sharing  between  nodes  of  the  network  and  the  degree  of  controllability  at 
various  nodes  will  give  the  system  tremendous  flexibility  and  adaptability  to  meet  anticipated  increases  in 
enemy  capability. 

That  is  the  system  concept  in  its  broadest  context.  What  you  are  discussing  here  will  form  a  subset  of 
this  total  concept.  The  technology,  the  tools,  the  methods,  the  advances  that  will  be  caused  by  you,  ladies 
and  gentlemen  of  AGARD,  are  vital  to  (he  overall  effort.  Keep  your  minds  'lo  new  ideas  and  rememberyou 
are  in  the  vanguard  of  this  integrated  approach  to  a  total  systems  concept. 

This  total  systems  concept  is  uppermost  in  our  minds  within  my  command,  where  we  are  plowing  new 
ground  as  we  embark  on  designing  the  U.S.  Navy's  battle  force  as  a  system  —  more  from  the  top  down 
rather  than  the  bottom  up.  WeVe  never  tried  this  before. 

One  might  ask  the  questions:  Why  do  we  want  to  take  on  what  is  clearly  a  complex  engineering 
management  usk?  Why  not  keep  doing  what  weVe  been  doing,  which  has  been  reasonably  successful?  My 
answer  is  that  we  must  change  our  way  of  doing  business  if  we  are  to  take  full  advantage  of  the  technological 
explosion,  and  we  must  cope  with  our  adversary's  application  of  that  same  technology.  Technology  has 


significantly  shrunk  the  battle  zone,  whether  it  is  sea.  land,  or  air.  This  fact  alone  requires  us  to  design  a 
much  more  highly  integrated  battle  force  —  one  that  is: 

•  Effective  against  potential  threats. 

•  Assures  us  that  we  have  functional  redundancy,  but  only  where  we  want  it. 

This  requires  a  well  system-engineered  battle  force. 

We  are  already  embarked  on  this  total  systems  concept  to  which  1  have  alluded,  as  a  result  of  a  major 
change  in  the  way  the  Navy  wants  to  design  and  acquire  its  battle  forces  of  the  future.  This  is  no  small  task . 

Heretofore,  the  application  of  a  comptehensive  system  engineering  approach  in  the  U.S.  Navy  has  been 
limited  almost  entirely  to  systems  no  larger  than  individual  major  weapon  systems,  e.g..  FB  VI,  AEGIS,  and 
aircraft  systems.  We  have  never  had  the  organization  nor  the  dedication  to  approach  the  design  of  our  total 
battle  force  through  the  application  of  systems  engineering  techniques  and  disciplines.  We  have  now 
established  that  organization  and  signaled  the  intention  to  change  our  way  of  doing  business. 

1  would  like  to  talk  about  some  ofourearlyeffoitsduhng  the  past  16  months  of  work.  Having  first  been 
tasked  by  the  Secretary  of  the  Navy  almost  two  years  ago  to  develop  a  process  for  system  engineering  the 
Navy,  we  were  later  tasked  by  the  Vice  Chief  of  Naval  Operations  to  tackle  battle  force  command  and 
control  as  a  first  and  critical  opportunity. 

We  began  the  job  of  developing  a  BFC^  architecture  by  doing  that  top-down  and  bottom-up  analysis  of 
Navy  functions.  We  then  aggregated  these  functions  into  loosely  coupled  major  systems  using  a  set  of  self¬ 
generated  architectural  principles. 

We  refer  to  these  loosely  coupled  battle  force  warfare  systems  as  (1)  tactical  command  systems,  (2) 
communication  support  systems,  (3)  warfare  support  systems,  and  (4)  weapon  systems,  battle  force 
command  and  control  consisting  of  the  first  three.  Let  me  give  you  a  brief  descnption  of  these  battle  force 
command  and  control  ‘^varfa^e  systems”  we  have  developed. 

In  our  scheme,  each  of  these  systems  would  be  specified  by  an  operational  requirement  derived  from  a 
battle  force  top-level  requirement.  These  systems  would  be  designed  as  a  system,  budgeted  as  a  system,  and 
managed  as  a  system.  Now  let  me  say  a  few  words  about  each. 

The  tactical  command  system  will  be  a  repository  of  data.  Its  primary  concern  will  be  to  the 
man/  machine  interface  that  supports  Navy  command  authority.  The  principal  objective  is  to  enhance  Navy 
command  and  control  by  providing  our  warfare  commanders,  at  all  levels,  with  an  accurate  and  consistent 
tactical  picture  while  minimizing  the  number  of  independent  developments. 

The  communication  support  system  can  be  envisioned  as  the”Ma  Bell”  system  for  the  Navy.  It  treats  all 
general-purpose  data  and  voice  communications,  message  standards,  and  communications  processing 
elements  as  a  system. 

The  idea  is  to  pass  from  the  other  warfare  systems  the  information  that  needs  to  be  tiansferred  to  other 
Navy,  Department  of  Defense,  or  allied  units,  and  let  the  system  process  that  information  into  the  correct 
format  for  delivery. 

Finally,  there  is  the  warfare  support  system.  This  system  contains  all  wide-a-?a  and  force-level 
surveillance  systems,  such  as  space  sensors,  and  undersea  surveillance  systems,  along  with  the  sea-  and 
shore-based  systems  that  detect  and  correlate  all  contact  data. 

In  the  past,  elements  of  this  system  have  been  treated  quite  separately  as  either  shore-based  or  afloat- 
based  systems  without  benefit  of  a  top-down  system  architectural  approach  which  would  permit  rigorous 
application  of  tradeoff  analysis  and  system  engineering  disciplines  in  determining  the  optimum  constituents 
of  this  system  and  defining/ controlling  interfaces  between  these  constituents. 

Our  architecture  calls  for  the  engineering  of  these  elements  as  one  large  system  using  system 
engineering  disciplines  that  have  proven  so  useful  in  designing  major  weapon  systems. 

Last  November,  the  Vice  Chief  of  Naval  (^rations  approved  this  conceptual  architecture,  and  we  are 
now  conducting  a  more  detailed  design  definition  and  working  to  define  a  transition  plan  to  this  new  system 
design  for  the  three  warfare  systems.  In  addition,  we  have  begun  work  to  describe  an  architecture  for  each  of 
the  three  major  warfare  areas:  antiair  warfare,  antisubmarine  warfare,  and  antisurface  warfare. 

This  approach  represents  a  new  way  of  designing,  budgeting,  and  managing  the  Navy's  warfare 
systems. 

There  are  many  other  activities  that  we  are  working  on  that  bear  on  improving  our  ability  to  provide  a 
well  system-engineered  battle  force. 
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One  ot  the  most  exciting  things  wearedoingisanefiortcaiJed  the  Fleet  initiatives  Program.  This  effort 
is  moving  ovt  quickly  to  couple  more  closely  the  Navy  material  establishment  with  our  operating  forces. 

We  have  established  a  supporting  organization  for  this  effort,  and  we  are  working  on  new  fleet- 
prioritized  ideas  which  employ  commercial  computer  resources  to  rapidly  prototype  tactical  command 
systems.  This  effort  provides  an  opportunity  for  us  to  learn  iLc  type  of  system  that  best  supports  our  force 
commanders  and  allows  us  to  write  better  specifications  for  development  contracts.  Where  appropriate,  it 
gives  our  tket  commanders  an  inteiim  capability,  and  if  the  acquisition  cycle  continues  to  lengthen,  it  might 
be  their  only  capability. 

This  program  is  also  working  on  fleet  priorities  that  cause  changes  to  existing  military  systems  for 
experimental  woik,  such  as  third-party  targeting. 

Some  of  these  prototypes  involve  new  technology,  like  the  artificial  intelligence  work  the  Defense 
Advanced  Research  Projects  Agency  is  funding  to  build  the  fleet  command  center  for  battle  management  at 
CINCPACFLT.  All  of  these  are  exciting  efforts  that  will  be  continuing. 

To  continue  our  architecture  work,  we  are  building  the  databases  of  operational  and  system  functions 
to  translate  top-level  warfare  requirements  being  written  by  offices  within  the  Chief  of  Naval  Operations 
into  designs  and  engineering  solutions  for  the  appropriate  weapon  system. 

We  are  also  beginning  to  evaluate  existing  development  option  papers  in  the  weapon  systems  to  assure 
that  proposed  solutions  meet  the  direction  planned  for  the  architecture.  As  an  example,  we  are  rethinking 
the  electronic  warfare  control  system  to  allow  the  necessary  tight  coupling  between  hard-kill  and  soft-kill 
weapons. 

In  the  warfare  system  engineering  work,  we  arc  coming  to  closure  on  the  concept  that  we  plan  to  use. 
This  engineering  work  should  provide  more  stability  for  our  program  managers.  We  will  create  warfare 
system  performance  specifications  and  warfare  system  control  interface  drawings  as  the  mechanisms  that 
will  establish  that  stability  between  and  among  warfare  systems. 

I  sec  these  new  thrusts  in  our  Navy  as  exciting  opportunities  for  the  Navy  to  begin  buildinga  future  that 
will  sustain  this  country  in  its  maritime  strength  and  provide  the  President  with  the  means  to  maintain  our 
commiimem  to  the  free  world. 

1  view  these  activities  as  the  most  challenging  enterprise  that  the  Navy  has  initiated  in  past  decades. 
Now  it  is  time  for  me  to  step  aside  and  let  this  Panel  get  down  to  work. 


Thank  you  for  inviting  me  to  be  your  speaker,  and  good  luck  in  your  deliberations. 
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WilliAB  T.  Suit  Douglas  B.  Pcic^ 
MASA  Langley  Resear^  Center 
Spacecraft  Control  Branch 
Hampton,  VA  2i66S*'S22S 
USA 


In  1985,  a  presidential  directive  initiated  the  National  Space  Transportation  and  Support  Study  which 
instructed  NASA  and  the  OOD  to  look  at  the  national  needs  for  large  aysten  architectures,  avionics,  and 
mis'ilon  requirements  to  support  the  design  of  space  transportation  systems  through  the  year  2010.  The  pur¬ 
pose  of  the  joint  NASA-OOO  program  resulting  from  the  directive  was  to  conduct  studies  to  determine  tne 
technology  development  required  for  the  design  of  the  next  generation  of  space  transportation  systems. 
These  objectives  are  discussed  in  greater  detail  in  reference  1 .  Much  of  the  proposed  research  is  mission 
motivated,  and  vehicle  operations  will  be  the  focal  point  for  this  research.  In  this  paper,  m  will 
primarily  diacuse  NASA'a  input  tu  the  avlonica  technology  development  plan. 

While  control  issuea  are  critical  In  the  design  of  propulsion  systems  and  airframes,  a  major  task  is 
the  development  of  operational  simplicity  leading  to  significantly  lower  costa.  When  discussing  the  next 
generation  of  space  transportation  systems  t<ords  such  as  "autonomoua,**  "adaptive,”  and  "on-line”  are  used. 
If  single  vehicles  are  to  be  operated  more  efficiently  or  If  multiple  vehicles  are  to  be  supported  by 
limited  onboard  crews  and  ground  support  staff,  many  operational  functions  will  have  to  be  handled  by 
vehicle  avlonica  systems. 

Several  examples  will  illustrate  this  point.  Retargeting  for  new  missions  can  currently  require  days 
for  reprogramming,  while  the  proposed  vehicles  will  need  the  capability  of  retargeting  in  minutes.  A  cur¬ 
rent  manned  mission  requires  an  extensive  ground  suf^ort  network,  while  in  the  future,  several  manned  vehi¬ 
cles  could  be  operating  at  the  same  time  with  only  limited  around  or  apace  station  support  available.  The 
next  generation  of  vehicles  nust,  therefore,  be  autonomous  and  require  only  minimized  outside  support. 

The  research  plan  to  develop  the  technology  base  required  to  meet  the  avionics  needs  of  the  2lst 
century  space  transportation  systems  was  put  together  by  technical  representatives  from  NASA  and  DOD.  It 
represents  their  best  estimate  of  the  research  areas  necessary  to  expand  the  current  technology  base 
required  before  actual  vehicle  design  can  begin.  This  program  will  serve  as  a  basis  for  research  require¬ 
ments  and  ths  tims  necessary  for  their  development.  The  plan  developed  has  been  divided  into  major 
categories.  These  are: 

duidancs.  Navigation  and  Control 

2.  Plight  Systems  Management 

3.  System  Integration  and  Modelling 

4.  Communications 

5.  Man/$y6tewa  Interface 

These  categories  will  be  further  divided  into  subcategories  with  specific  objectives.  The  extent  to  which 
this  plan  is  implemented  will  determine  how  much  of  the  suggested  technology  base  will  be  available  for  the 
desi^i  of  future  space  transportation  systems. 

This  paper  will  assume  full  implementation  and  will  discuss  these  categories  and  objectives  with 
emphasis  on  the  mission  requirements  they  will  satisfy.  Since  this  Is  a  long-term  program  that  Is  just 
beginning,  few  results  are  available.  The  current  studies.  In  many  cases,  eire  extensions  of  existing  work 
and  are  general  in  nature,  but  are  directed  toward  GN&C  algorithms  and  flight  systems  that  will  result  in 
an  autonomous  vehicle.  A  test  program  to  demonstrate  the  concepts  developed  has  been  proposed,  and  this 
test  program  and  its  necessity  will  be  discussed.  A  suBMry  of  the  goals  and  potential  impact  of  the  tech¬ 
nology  plan  will  conclude  the  paper. 


DI8CD88I0H  OP  KSUICB  CAnOOUBS 

Initially,  the  current  state  of  the  art  nust  be  established.  The  Space  Shuttle  will  be  considered 
representative  of  the  current  state  of  the  art,  and  this  paper  will  Indicate  improvoaents  in  the  current 
systems  required  to  meet  the  needs  of  follow-on  vehicles.  As  the  different  categories  are  discussed,  the 
results  of  the  proposed  research  will  be  related  to  various  proposed  missions  and  experiments. 

A  discussion  of  the  research  categories  follows: 

1.  Guidance,  Navigation  and  Control  (GNac) 

GN6C  technologies  will  be  developed  to  achieve  on-demand  launch/recovery,  precision  rendezvous  and 
docking,  and  in-space  operations  without  ground  support.  This  effort  includes  developments  required  to 
achieve  adaptive,  all-weather,  optimal,  autonomous,  fault-tolerant,  onboard  guidance,  navigation  and  con¬ 
trol.  Critical  tasks  include  the  develo^nent  of  algorit?ims  and  the  associated  subsystems  required  to  sup¬ 
port  autonomous  GNSC.  The  associated  subeystems  include  attitude  reference  systois,  fll^t  data  sensors, 
actuators  end  supporting  processors. 

To  accomplish  the  GM&C  objectives,  seven  research  elements  have  been  identified.  T^ese  ere;  1.  GNAC 
Syeten  Modeling,  2.  Algorittmi  Development,  3.  Sensore,  4.  Actuetora/Control  Effectors,  5.  Attitude 
Reference  Systems,  6.  supporting  Processors,  end  7.  Ground  Test  Slmuletions. 
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Mission  needs  require  that  various  research  eleaents  or  groups  of  elements  be  accomplished.  New 
guidance,  control  and  navigati(»  algorithms  must  be  developed  to  achieve  the  on-d«aand,  autonomous,  all- 
weather  operation  desired  for  the  next  generation  of  ^ace  vehicles.  Improved  instruments  are  required  to 
support  the  algorithms  developed,  and  these  must  be  smart,  self-checking,  self-healing,  and  fault-tolerant 
to  give  a  very  reliable  system.  The  concepts  of  redundancy  and  reliabllty  will  have  to  be  redefined  in  the 
new  environment,  and  this  redefinition  will  also  be  part  of  the  proposed  research.  The  object  of  the 
avionics  systems  for  future  vehicles  Is  greater  reliability  with  reduced  saintenance. 

The  proposed  research  programs  to  accomplish  the  objectives  outlined  above  are:  1.  Algorithms  for 
Autonomous  GM6C,  2*  Navigation  System  Requirements,  3.  Subsystems  Development,  and  4.  Vehicles  Dynamics 
Modeling.  Milestones  for  accompll;^hing  various  objectives  in  the  research  programs  are  shown  as  Table  I. 


TABLE  I.  Research 

Program 

Milestones 

For  The 

Guidance, 

Navigation 

and 

Control 

Category . 

YEAR  87 

88 

89 

90 

91 

92 

93 

94 

95  96 

1 

2  3 

4 

6 

7 

9 

_ 

5 

8 

I  Milestones 

I  1.  Ascent  guidance/control  algorithms  demonstrated 

2.  ''.uub  ..avigatlon  algoritiims  demonstiated 

3.  Rendesvous/docking  guidance  syatesis  defined 

j  4.  Aero-assist  Orbital  Transfer  Vehicle  (aOTV)  atmospheric  guidance  algorithms  demonstrated 
^  5.  Air  <l9ta  sensor  technology  available 

6.  Attitude  reference  system  technology  ready 

7.  Autonomous  automatic  navigation  system  ready 
6.  Entry  control  algorithms  ready 

9.  Unmanned  GH&C  system  simulation  completed 


The  research  elements  should  be  satisfied  and  the  programs  completed  by  1996  so  that  final  design  of 
various  aerospace  vehicles  c^n  begin. 

2.  Flight  Systems  Management 

Flight  Systems  Management  technology  advances  are  sought  in  three  major  areas:  1.  Automated  System 
Health  Monitoring  and  control,  2.  onboard  Mission  Planning  and  Retargeting,  and  3.  Flight  Operations 
Management.  The  system  health  studies  will  permit  advanced  knowledge-based  systems  to  perform  self-test/ 
diagnostic  tasks,  display  risk  evaluations  and  initiate  appropriate  reconfigurations  or  other  corrections. 
Onboard  mission  planning/retargeting  developments  will  allow  fast  reaction  to  changed  mission  requirements 
or  parameters.  Critical  aspects  center  on  the  ability  to  develop  and  check-out  adaptive,  fast  reactive 
software  retargeting  algorithms.  Developed  algorithms  will  be  tested  in  laboratory  simulations.  Flight 
operations  management  techniques  will  allow  real-time  redirection  o'  reconfiguration  of  subsystems.  System 
tests  will  be  conducted  to  demonstrate  integrated  technologies. 

The  research  elements  for  the  Flight  Systems  Management  category  are:  1.  System  Health 

Determination,  2.  Onboard  Mission  Planning/Retargeting,  and  3.  Flight  Operations  Management.  The  health 
determination  research  element  dictates  the  developtaent  of  systen  checks  to  see  if  hardc^are/software  combi¬ 
nations  are  working  properly.  Simulations  will  be  designed  to  establish  conditions  to  be  met  by  GN&C  algC' 
rlthms  for  nominal  missions  and  missions  with  changes.  This  onboard  mission  planning  and  retargeting  will 
greatly  reduce  the  ground  support  required  «tering  a  mission.  For  manned  missions,  the  information  about 
vehicle  health,  retargeting  or  other  automated  mission  operational  functions  will  be  displayed  to  the  pilot 
in  such  a  manner  that  he  can  react  to  this  information  and  take  any  actions  required. 

The  research  programs  proposed  in  the  Flight  Systems  Management  category  are:  i.  Autonomous  Flight 
Systems  Management,  and  2.  Systems  Health  Determination.  These  are  general  research  programs,  and  the 
specific  milestones  showing  when  results  can  be  expected  are  shown  as  Table  ll. 

TABLE  tl .  Research  Program  Milestones  For  Ihe  Flight  Systems  Management  Category. 


YEAR 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

1 

2 

5 

3 

4 

6 

7 

8 

:  .  ' 

'Milestones 

1.  Launch  operations  concepts  defined  and  evaluated 
I  2.  Launch  operations  design  requirements  defined  and  evaluated 

I  3*  Launch  operations  algorithms  developed  and  tested 

4.  Launch  operations  systems  demonstration  completed 

5.  Complete  mission  concepts  defined  and  evaluated 

6.  Complete  mission  design  requirmnents  defined  and  evaluated 

7.  Complete  mission  algorithms  developed  and  tested 
8*  Coiq)lete  mission  eystmu  demonstration  completed 
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3.  Systens  Integration  and  Modeling 

Candidate  avionics  technology  and  subsysteaw  Architecture  concepts  will  be  explored  to  identify 
building  blocks  for  custoa  configuration  of  autonoaoue,  fault* tolerant  avionics  systems.  Methodologies 
will  be  developed  for  evaluating  various  approaches  to  assure  synergistic  benefits^  optimization  and  system 
compatibility.  Critical  tasks  Include  system  concepts  definition  and  the  derivation  of  analytical  models 
for  evaluating  system  performance  and  coat.  A  systMs  test  bed  is  proposed  to  facilitate  systfm  level 
trade  studies  of  conceptual  design  candidates. 

The  research  elMents  for  the  Syateam  Intagration  and  Modeling  Category  are:  1.  Integrated  System 
Concepts,  2.  System  Dynamics  Analysis,  3.  Systems  Performance  end  Cost  Modeling,  and  4.  Systems  Test 
Beds.  Design  end  testing  programs  will  be  required  to  meet  the  Systems  Integration  and  Modeling 
objectives.  These  will  be  used  to  assess  the  Isipact  of  rarious  design  philosophies  for  syateme  ranging 
from  computer  architectures  to  combinations  of  structures  and  propulsion  systems.  The  test  beds  developed 
will  be  used  for  on-ground  certlficstion  of  various  design  concepts.  Advanced  inforsmt ion-processing  con- 
cspts  will  be  required  to  support  the  programs  developed.  some  of  the  programs  developed  could  be 
converted  to  operational  flight  aids. 

The  research  programs  Initiated  to  satisfy  the  Syeteirs  Integration  and  Modeling  category  are: 

1.  Advanced  Information  System,  2.  Aero-aaelet  Plight  Experiment  Avionics  Simulation,  3.  Design 
Specifications,  4.  Pault-tolarant  Architecture,  5.  System  Performance  Evaluation.  The  mlleatones  showing 
the  completion  targets  for  different  portiona  of  the  research  are  shown  as  Table  III. 

TABLE  III.  Reaearch  Program  Milestones  For  The  Syeteme  integration  And  Modeling  Category. 


YEAR 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

1 

2 

3 

6 

4 

7 

5 

e 

9 

10 

_ 

'  Milestones 

prototype  CTV/AOIV  syateme  concepts  defined 
!  2.  prototype  OTV/AOTV  analytical  BX>dels  developed 

3.  Prototype  OTV/AOTV  systems  concepts  analyzed 

4.  prototype  OTV/AOTV  systems  teat  beds  operational 

5.  prototype  OTV/AOTV  systems  trades  completed 

6.  Multimission  vehicle  systems  concepts  defined 

7.  Multlmission  vehicle  analytical  modals  developed 
6.  miltlaisslon  vehicle  systems  concepts  analyzed 

9.  Multlmission  vehicle  systems  test  beds  operational 
10.  Multimission  vehicle  systems  trades  completed 


4.  Communications 

Jam-resistant  communications  technology  will  be  developed  for  all  mission  phases,  with  emphasis  on  the 
on-orbit  and  reentry  blackout  phases.  Current  ocmnunicatlon  technology  procedures  will  be  reviewed  to 
Identify  specific  limitetions  end  problems  areas.  Ongoing  programs  will  be  focused  on  space  transportation 
needs.  Critical  concepts  and  disciplines  include  autonomous/secure  conmur.ications,  adaptive  swltlfunction 
antenna  systems,  multiple  beam  formulations,  and  phased  array  semiconductor  laser  comunications.  Antenna 
system  improvements  will  reduce  rellsncs  on  ground  station  support}  laser  ooimiunlcatlon  developments  will 
be  applicable  to  on-orbit  operations,  especially  for  data  collectlcm  and  reporting  of  aelf-monitoring 
system  studies.  Laboratory  component  testing  will  be  conducted  to  validate  the  technology  at  the  component 
level.  The  integrated  system  technology  will  be  demonstrated  In  a  flight  test. 

The  research  elements  for  the  Communications  category  are:  1.  Jam  Resistance,  2.  Reentry  Blackout, 
3.  Antenna  Design,  4.  Coverage  Bandwidth,  5.  Data  Transmission  Rate/Reliability,  and  6.  Coding  and 
Decoding.  The  oonnunications  system  is  to  be  designed  to  be  operative  throughout  the  operational  range  of 
the  vehicle:  from  orbit,  through  in-atmoaphere  maneuvering,  to  landing.  This  is  to  be  accomplished 

throu^  antenna  design  and  through  the  use  of  the  laser  techniques  required  to  transmit  large  amounts  of 
data. 


The  research  programs  for  the  Communications  category  are:  1.  Focused  Ooemunioations/Tracklng, 

2.  Optical  waveleng^  Division  Multiplexing,  and  3.  Real-time  Image  Processing  Algorithms.  The 
milestones  giving  the  projected  oompletion  of  portions  of  the  research  programs  zrs  shown  as  Tatble  IV. 

TABLE  IV.  Research  Program  Milestones  For  The  Communications  Category. 


TEAR  87  88  89  90  91  92  <>,3  94  95  96 

t  2  3 


Milestones 

I  1.  CoBiponent  technology  available 

I  2.  pli^t  test  oompletsd 

3.  System  technology  available 


5-  Man/SystM  Interface 


The  huaen  factors  technology  base  will  be  extended  to  support  developaent  of  an  optimised  man/machine 
Interface  through  applications  of  automation  and  electronic  display/ control  technologies.  Methodologies 
for  consolidating  controls*  integrating  displays  and  Improving  crew  station  design  will  be  established. 
This  effort  will  identify  requirements  and  opportunities  for  increasing  performance  with  new  control  and 
display  technologies*  and  determine  hi^  payoff  items  related  to  human  factors*  information  management,  and 
decision  support.  Bq>hasis  will  be  placed  on  a  eyat«u  approach  to  achieve  intelligent  aan/system  inter¬ 
faces.  Development  of  the  ability  to  synthesise  and  evaluate  candidate  system  concepts  is  an  important 
element  of  this  task.  Element  technologies  will  be  validated  by  laboratory  demonstrations. 

The  research  elements  for  the  Man/Syst«i  Interface  category  are:  1.  Crew  Station  Automation, 
2.  Control  and  Display  Devices*  3.  Intelligent  Interfaces*  4.  Human  Factors,  5.  information  Management, 
and  6.  Decision  Support.  Th*  Man/Syst«  Interface  category  is  divided  into  two  areas,  remote  manipulation 
and  vehicle  status.  In  either  case,  information  must  be  passed  to  the  crew  so  that  the  decision  required 
to  accomplish  a  mission  can  be  made.  Whether  controlling  a  remote  arm  or  retargeting  a  rendeevous 
maneuver*  the  displays  that  furnish  the  crew  information  oust  be  simple  but  also  complete.  Properly 
designed  displays  can  reduce  crew  workload  and  increaee  efficiency. 

The  research  program  established  to  meat  the  Man/System  interface  objectives  is  as  follows: 
1.  Control  and  Display  Devices,  2.  Man-machine  Interface,  and  3.  Han-machine  Interface  Technologies. 
The  accomplishment  milestones  for  this  research  program  are  sh.own  as  Table  V. 

TABLE  V,  Research  Program  Milestones  For  Han/Systam  Interface  Category. 


YEAR  87  86  89  90 

91 

92 

93 

94 

95 

96 

1  2 

3 

4 

5 

6 

7 

Milestones 

1. 

Requirements  identified 

2. 

High  payoff  areas  established 

3. 

Information  management  dlaplay  developed 

4. 

Preliminary  Integrated  display  developed 

5. 

Integrated  display  technology  available 

6. 

Refined  automated  control  system  developed 

7. 

Refined  multimode  pictoiial  displays  developed 

The  preceJing  sections  have  outlined  and  given  motivation  for  the  research  that  will  develop  tne 
technology  necessary  to  design  the  next  generation  of  space  transportation  systems.  Vie  will  next  discuss 
programs  for  validating  and  demonstrating  the  technology  developments  previously  discussed.  A  figure  from 
reference  f  (fig.  t)  will  help  put  the  demonstration  programs  in  perspective.  In  this  paper,  we  are  con¬ 
sidering  only  the  avionics  psrt  of  the  program  elements  shown  on  the  figure.  The  projects  proposed  can  be 
ground  tests  or  flight  sxperiments.  In  general,  eac^  demonstration  incorporates  a  number  of  advanced  tech¬ 
nologies  and  nay  also  utilita  new  operational  concepts.  These  projects  support  the  completion  of 
appropriate  milestones  shown  In  Tables  I  through  V. 

IgPHEBBWATTTt  MPMOTWATIOli  FIIOJSCTS 

The  following  is  a  discussion  of  five  typical  demonstration  projects,  which  could  be  used  to  show  that 
various  technologies  have  been  developed  to  the  point  where  actual  designs  exploiting  these  technologies, 
can  begin.  The  demonstration  projects  to  be  discussed  are:  1.  Optimized  Guidance  Algorithms,  2. 

Advanced  Avionics  Systems,  3.  Autonomous  Launch  Capability,  4.  Advanced  Information  processing  Systems, 
S.  Space  Transportation  System  Oommunlcation  Blackout. 

1.  Optimized  Guidance  Algorithms 

The  objective  of  this  project  is  to  provide  validated  guidance  algorithms,  indexed  by  mission 
objective  vehicle  type,  that  permit  real-tlaie,  onboard,  and  optimal  flight  path  selection.  This  pro¬ 

ject  will  lead  to  a  ground  demonstration  of  Entry  Vehicle  landing  and  aerodynamic  plane  change  capabilities 
in  1993.  A  flight  demonstration  of  guidance  algorithms  for  landing  and  aerodynamic  plane  changes*  which 
would  also  support  planetary  aerocapture  and  landing  technology  readiness,  is  proposed  for  1994.  A  demon¬ 
stration  in  this  time  frame  would  support  milestones  8  and  9  of  Table  I,  milestone  7  of  Table  ll  and  all 
milestones  of  Table  III. 

2.  Advanced  Avlonlca  Syatevs 

This  project  will  validate  modeling  tools  to  enable  In-fllght  subsystems/controls  reconfiguration, 
demonstrate  software  for  autonomoris  GM4C,  demonstrate  emerging  photonics  technology  devices  and  processes 
for  integrated  optical  control  systems,  and  demonstrate  advanced  power  distribution.  The  advanced  power 
distribution  system  with  fault-tolerant  capability  is  to  be  demonstr  ted  In  1991.  in  conjunction  with  the 
Optimized  Guidance  Algorithms  project,  an  autonomous  guidance  and  navigation  system  design  technology  is  to 
be  ready  in  1994.  A  photonic-based  device  eyetw  design  will  be  demonstrated  in  1994*  and  a  complete 
avionics  system  will  be  demonstrated  for  an  AOTV.  This  project  will  support  mileetcree  5  through  9  of 
Table  I,  milestones  7  and  8  of  Table  II*  milestone  9  of  Table  HI,  and  milestone  6  of  Table  V. 


3. 


AutonoBous  launch  Capability 


This  project  will  incorporate  otany  of  the  results  fron  the  previous  studies.  Its  objective  is  to 
develop  the  capability  for  prelaunch  cooeilt-to-f light  detensination  based  on  cxiboard  simulation,  check>out, 
and  loads  prediction;  and  develop  capability  for  onboard  real-time  retargeting,  load  relief,  and  abort 
decisions.  The  requirements  will  be  defined  for  onboard  simulation,  d\ec)c-out,  loads  prediction,  environ¬ 
ment  iseasureBents,  and  GNftC  algorltham  in  1991.  This  requirements  definition  relates  directly  to  mile¬ 
stones  1  and  2  of  Table  I  and  milestones  1  throu^  4  of  Table  XI.  instruments  for  onboard  environment 
measuresMnts  will  be  available  by  1994.  The  technology  required  for  these  instruments  «rere  shown  as  mile¬ 
stone  5  of  Table  I.  A  simulation  for  the  prelaunch  and  launch  phases  of  the  demonstration  will  be  avail¬ 
able  in  1994.  This  development  is  supported  by  milestone  9  of  Table  I  and  milestone  9  of  Table  III.  A 
ground-based  demonstration  of  an  autonosioua  launch  will  be  scheduled  for  1995.  The  flight  instrumentation 
and  software  will  be  developed  by  1998  for  a  fli^it  test  on  the  shuttle  with  parallel  ground-based  monitor¬ 
ing  set  for  2000.  Thla  flight  test  could  be  a  partial  fulfillment  of  milestone  8  of  Table  ll  and  milestone 
10  of  Table  III-  The  extent,  to  «rhich  this  demonstration  may  verify  the  Han/Systoa  Interface  research,  has 
not  been  defined. 

4.  Advanced  Information  processing  Systems 

The  objective  of  this  demonstration  project  is  to  provide  validated  technology  for  real-time  fault 
tolerant  and  distributed  control  systests  based  on  a  sound  theoretical  foundation,  mature  reliability  and 
performance  tools  and  operating  hardware  beeed  on  fault-tolerant  building  blocks.  Validation  concepts  for 
operating  system  hardware  and  software  will  be  eetabllahed  In  1989.  Also,  a  control  architecture  simula¬ 
tion  for  an  and  the  Aero-assist  Plight  Deperiment  will  be  developed  by  1989.  Design  guidelines  for 

hardware,  software  and  validated  performance  and  reliability  tools  will  be  established  in  1991.  integrated 
real-time  fault-tolerant  distributed  control  technology  and  Advanced  Transportation  System  control  archi¬ 
tecture  technology  will  be  ready  by  1992.  The  Information  Processing  destonstration  will  impact  the  three 
preceding  demonstration  experiments. 

5.  Coamunication  Blackout 

The  Coamiunication  Blackout  demonstration  has  no  direct  link  to  the  other  research  programs  or  demon¬ 
stration  projects,  but  its  success  will  impact  all  missions.  The  objective  of  the  demonstration  is  to 
develop  antenna  design  and  placement  methodologies  and  techniques  to  minimise  or  alleviate  oonunications 
blackout  during  high-speed,  high-altitude  atmospheric  flight.  Since  the  blackout  is  a  function  of  the  ion¬ 
isation  layer  structure  about  the  vehicle,  the  development  of  computational  fluid  dynamics  (CPD)  codes  to 
describe  the  ionisation  structure  la  required.  Non-equilibrium  CF1>  codes  will  be  developed  by  1989.  CFD 
codee  will  be  extended  to  eetimate  leeside  free  electron  numb'^r,  density,  and  ionisation  layer  structure  in 
1990.  Also,  by  1990,  techniques  for  alleviating  blackout  will  be  developed,  including  an  experimental 
approach  and  instrumentation  for  their  validation.  CPD  code  validation  for  AOTV-type  vehicles  using  Aero- 
assist  Plight  Experiment  results  will  be  available  by  1993.  The  demonstration  project  relates  directly  to 
the  Oommunlcatlons  research  program  and  supports  all  three  milestones. 

The  successful  completion  of  the  dcusonstratlon  projects  should  coincide  with  the  natuting  of  the 
research  programa  to  the  point  that  the  technology  developed,  at  that  rime,  can  be  considered  ready  to  be 
Incorporated  into  vehicle  designs.  Based  on  the  technology  available,  decisions  can  be  made  as  to  which  of 
the  final  designs  are  most  practical  (fig.  1). 


mmiuvs 

in  this  paper,  a  program  to  smet  the  avionics  technology  needs  for  the  design  of  future  space 
transportation  systems  has  been  outlined,  a  more  general  discussion  of  the  proposed  research  program  and 
its  potential  problem  areas  for  both  NASA  and  DOD  is  given  In  reference  1.  This  discussion  gives  greater 
detail  for  specific  research  programs.  The  program  is  designed  to  meet  as  many  technology  goals  as  pos¬ 
sible  by  1996  so  that  dscialons  can  be  smde  as  to  which  vehicles  are  feasible  and  which  should  be  oon- 
structed.  The  reeearch  program  has  been  established  based  on  mission  profiles  that  are  coonon  to  many 
vehiclss.  The  time  linee  established  for  this  research  program  are  based  on  a  full  funding  as8uiq>tion  and 
could  slip  or  have  to  be  limited  if  this  assumption  is  not  met.  As  of  this  time,  priorities  have  not  been 
set  on  the  varloue  programs  listed. 

The  desionstratlon  projects  listed  are  only  a  sampling  of  ths  verification  tests  required  to  determine 
that  the  technology  Is  ready  to  be  used  in  a  vehicle  design  process.  An  examination  of  the  research  pro¬ 
gram  milestones  shows  that  other  demonstrations  will  be  required  to  validate  the  results  of  all  the 
research  programs. 

As  pointed  out,  thie  peper  describee  a  program  that  is  just  beginning.  This  is  the  first  year  in 
which  significant  funding  of  programs  Is  expected.  The  Ingenuity  of  many  people  will  be  tested  to  make  the 
best  use  of  theee  funds  and  ar<-nmnllah  the  program  look  forward  to  an  Interesting  10 

years . 


1.  Walberg,  Gerald  D. ;  Gaeperich,  Lt.  Ool.  Prank  J.  Jr.;  and  Scheyhing,  Ernest  R. :  "National  Space 
Transportatlcxi  and  Support  Study /Technology  Requirements  and  Plans,"  AlAA  B6-1213-CP,  June  1986. 
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Pi.9ur«  1.  OcBonstr«tion  Concept 


DISCUSSION 

C'.Berggren,  US 

Have  you  quantified  the  real-time  requirements  tor  both  subsystem  reconfigurations  and  llight  path  selection 

Author's  Reply 

Studies  are  currently  under  way  to  address  these  questions.  Results  on  the  reconfiguration  issue  are  expected  in  the 
1 9H8  lime  frame  and  on  flight  path  selection  in  the  1 989  lime  frame. 
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SIMM  ARY 

To  a  large  degree  the  effectiv<*ness  and  affordability  of  systems  for  the  21st  C-entnry  will  d.-pend  on 
the  quality  of  "visioneering"  which  Is  applied  today.  Established  ways  and  means  of  system  definition, 
development  and  demonstration  are  rapidly  giving  way  to  a  new  set  of  criteria  based  upon  system 
modularity,  network  interconnectivity  and  total  system  simulation.  Avionics  system  engineering  has 
become  a  sub-set  of  a  total  composite  composed  of  avionics,  platform  and  external  interoperat  ion.ai 
environment.  It  is  these  three  components  which  must  be  ordered  as  a  total  system. 

In  order  to  cope  with  what  is  on  the  technical  horizon  we  must  accommodate  the  transition  from 
today's  Black  Box  avionics  to  a  future  21  Century  modular  partitioned  architecture.  An  Avionic  System 
Index  will  be  proposed  which  allows  for  the  definition  of  each  function  of  the  avionic  system. 

Also  the  results  of  two  demonstrations  conducted  by  the  NAVAIROEV'CEN  relative  to  the  exploitation  of 
on-board  avionics  built-in-test  and  diagnostics  will  be  presented. 


INTRODUCTION 

A  System  is  the  contemplation  of  order  achieved  by  direction  of  Its  implementation.  Such  a 
statement  denotes  a  transformation  from  tie  design  of  a  system  to  the  "Art  of  the  System"  (I). 
Development  and  implementation  of  Systems  for  the  2lst  Century  will  demand  the  insight  of  the  artist, 
the  skill  of  a  diplomat  and  a  very  high  degree  of  management  leadership.  Avionics  system  engineering 
has  become  a  sub-set  or  a  total  composite  consisting  of  the  avionics,  the  platform  and  the  external 
interoperational  warfare  environment.  Together  they  form  the  structure  for  fleet  air  operators  to 
exercise  their  skills  in  order  to  meet  mission  objectives. 

The  primary  cause  for  the  scope  of  this  totally  is  the  operational  need  for  coordination  between 
elements  of  our  forces  and  the  time  compression  of  emerging  technologies.  The  challenge  Is  for  proper 
minagement  and  direction  leading  to  the  development,  application  and  lraplemeni.it  ion  of  our  avionics 
systems  within  the  above  context. 

Advancing  technology  has  caused  the  avionics  engineer  to  work  with  an  ever  changing  equation  - 
decrease  equals  increase.  The  smaller  devices  become  the  more  capability  they  provide.  In  addition,  is 
the  fact  that  today's  design,  development,  and  procurement  practices  are  rapidly  becoming  outmoded  tn 
apply  to  t.morrow's  systems.  Simulations  and  computer  aided  design  (CAD)  have  replaced  the  drawir.»’ 
board.  Dedicated  logic  ftinctlo.s  are  being  replaced  with  a  computer  on  a  chip.  Human  decisions  arc 
being  replaced  by  machine  decisions.  Software  no  longer  instructs  a  machine  "How"  to  do,  but  rather 
"What"  to  do.  This  then  is  our  starting  point,  a  recognition  of  accelerating  change  and  the  resultant 
impact  on  the  ways  and  means  which  we  refer  to  as  "business  as  usual".  Additional  1  v,  we  must  recon.g !  7c 
the  interrelationships  which  exist  between  the  avionics,  the  platform,  and  the  w.irfare  area  er;v;  roi'mer.t  . 
It  is  within  this  framework  of  reference  that  the  systems  of  the  2lst  century  must  he  implemented  and 
operated.  Together  thev  form  "The  Art  of  the  System".  Just  as  a  movie  director  must  envision, 
coordinate  and  manage  all  actions  on  the  "Set"  so  too  must  the  te<hn:oaJ  manager  envis'on  the  (;pe'‘ar,  Ing 
scenario(s),  tactics  and  hardware  for  a  given  warfare  area  and  set  about  to  manage  and  direct  the  tntal 
composite.  Further,  it  is  precisely  because  of  these  conditions  that  we  must  set  goal®  and  ohicctlvc^ 
governing  the  application  and  implementation  of  emerging  technologies  :f  we  are  to  ach!  /e  maximum 
effectiveness  an  i  at  the  same  time  be  able  to  afford  the  promise  of  tec. .oology.  We  must  liavc  .i 
management  structure  which  provides  guidance  and  direction  in  the  form  ot  an  Avionics  Doctrine  or 
Policy.  it  is  only  by  having  a  common  set  of  rules  and  principles  directed  towards  a  common  obieclive 
that  we  will  be  able  to  affort  and  provide  the  weapons  system  capabilities  which  will  be  roquired  tcir 
the  21st  Century. 


DISCUSSION 

Figure  1  presents  the  observation  th.at  the  level  of  avionics  system  integration  is  directlv 
proportional  to  the  introduction  and  application  >f  solid  state  electronics.  The  application  of  the 
transistor  and  the  microchip  each  created  their  own  level  of  .system  Integration.  Each  allowed  tor  an 
increased  amount  of  compactness,  required  less  power  and  increased  the  degree  of  overall  system 
integration  by  allowing  for  the  introduction  of  integrated  control/display  panels,  embedded 
microprocessor  equipments  and  overall  system  interconnectivity  via  a  d.gltal  data  bus.  The  next  level 
of  avionics  integration  is  projected  to  "Step"  in  the  1989-1992  time  frame.  With  Lhe  availability  and 
application  of  VHSIC  technology  a  new  level  of  integration  will  be  achieved.  Hr.wevnr,  this  will  result 
in  a  "Giant  Step"  because  of  the  increased  allowability  of  related  technologies.  Smaller,  faster,  less 
power  and  greatly  increased  memory  capacity  has  given  rise  to  an  era  of  software  driven  avionics  such 
that  the  binary  function  has  become  "King".  The  introduction  of  VHSIC  will  open  the  door  to  numerous 
application  of  computer  science  In  the  form  of  data  fusion,  decision  aids,  expert  systems  and  artificial 
intelligence  (AI).  The  transition  from  the  transistor  to  the  microchip  resulted  in  the  t ransformat ion 
from  single  function  black  boxes  to  multi-function  black  boxes.  The  transition  from  the  microchip  to 
VHSIC  technology  will  result  in  the  transformation  from  the  multi-function  black  box  to  a  totally 
Integrated  aystem  interconnected  via  a  network  of  optical  high  speed  data  buses  (HSDB),  high  bandwide 
matrix  switches,  and  common  backplane  buses. 


APPLICATION  OF  TECHNOLOGY 
STEP  FUNCTION 


Figure  I 

Figure  2  illustrates  the  reality  of  avionics  Impleruentatlon  when  compared  to  a  specific  period  in 
time.  Systems  now  in  development  such  as.  Integrated  Comm.  Nav.  IFF  Avionics  (ICNIA)  -  Integrated 
Electronic  Warfare  Systems  (INEWS)  -  Advanced  Target  Acquisition  System  (ATAS)  -  Integrated  Inertial 
Sensor  Assembly  (USA),  will  not  be  available  at  the  same  time.  We  don't  have  the  luxury  or  reality  of 
starting  with  a  "clean  sheet  of  paper".  Equipment  availability,  present  inventory  and  supnort 
logistics,  and  degrees  of  risk  must  be  balanced  and  assessed  in  terms  of  specific  platform  schedules  and 
funding  profiles.  In  light  of  these  realities  we  must  apply  a  certain  degree  of  vision  by  setting  the 
stage  for  the  introduction  of  new  technologies.  We  must  set  up  the  framework  for  their  iiUroduction  via 
an  avionics  architecture  which  will  provide  the  allowability  factor  to  incorporate  technology  insertion. 
We  must  therefore  address  a  ways  and  means  which  offers  us  the  opportunity  to  incorporate  emerging 
technologies . 


Figure  2 

Figure  3  outlines  the  basic  framework  which  must  exist  if  we  are  to  define  a  systems  architecture 
governing  external  interoperability  and  Intra-platform  standardisation.  It  is  the  existence  of  these 
interface  networks  which  enables  operators  and  machines  to  "talk"  and  function  as  a  composite  entity. 
Standardization  is  a  key  factor.  Special  purpose  and/or  unique  systems  are  limited  in  application  and 
costly  to  develop,  implement,  operate  and  maintain. 

Within  the  external  spectrum  interoperability  Is  made  possible  by  standardization  of  messages,  RF 
modulation  and  data  link  protocol*  These  parameters  are  implemented  and  controlled  by  various  Tactical 
Data  Interchange  Link  (TADIL)  Standards,  voice  communications  procedures  and  equipment  specifications. 
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The  standardization  of  an  intra-plat fom  net%fork  was  begun  with  the  introduction  and  impleaentatlon 
of  the  DOO  H1L-STD-1553B  and  its  NATO  equivalent  STAMAG-3836  bus  network.  MiL-STI>-1553B  provided  a 
significant  step  forward  relative  to  avionics  systea  Integration.  For  tonorrov's  systeas  we  mist 
continue  %^th  the  developnent  and  iaplenentatlon  of  internal  aircraft  network  standards  governing  high 
speed  data  buses,  wide  bandwidth  switch  aatrlxes,  and  cobaoh  backplane  connectivity.  These  networks 
will  serve  as  the  fraoework  for  a  future  cosaon  Navy,  military,  avionics  architecture. 
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Figure  3 

Figure  4  illustrates  avionics  architectural  trends  based  on  both  government  and  Industry 
projections.  To  be  sure  there  are  many  other  similar  or  varied  versions  both  from  within  the  government 
and  from  industry.  However,  they  do  reflect  a  common  underlying  thesis.  That  is,  they  represent  a 
modular  time  shared  partitioning  of  functions  in  order  to  group  like  functions  into  some  type  of 
managable  architectural  structure.  It  is  to  be  noted  that  the  key  ingredient  which  allows  for  the 
interplay  and  construction  of  the  avionics  functions  is  the  one  of  a  common  intra-platform  network. 

This  is  the  framework  which  supports  the  architecture. 


[iiVtOWCS  CHfcHHtLl 
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Figure  4 

Figure  4  presents  the  concept  of  an  Avionics  Channel  to  replace  the  self  contained  dedicated 
channels  implemented  by  today's  black  box  systems.  The  advantage  of  this  type  of  architecture  is  that 
it  allows  us  to  define  functional  areas  of  operation  which  can  then  be  described  by  standard 
electrical/optical  interface  standards  for  networking  throughout  the  aircraft.  It  is  by  so  doing  that  we 
partition  areas  into  functional  domains  and  subsequently,  set  up  boundaries  which  can  be  defined  in  terms 
of  function  and  interface,  packaging  and  software  standards.  The  Intrastructure  I  have  chosen  Is  one  of 
a  System  Index  composed  of  Elements  (E),  Cells  (C),  and  Zones  (Z),  Figure  3.  The  basic  unit  of  the 
avionics  system  is  the  Element.  Elements  are  implemented  within  a  structure  of  Cells  which  in  turn 
occupy  a  Zone.  Such  an  arrangement  is  viewed  as  a  means  of  defining,  describing  and  local ..ng  any 
Element  of  a  system  slmiliar  to  having  an  avionics  library  of  functions  from  which  to  choose  and 
manipulate  in  order  to  construct  and  satisfy  the  requirements  of  a  particular  aircraft  avionics  system. 
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1q  practice  the  avionics  ayatea,  Figure  S,  la  partitioned  Into  three  functional  Zones.  An  Outer 
Zone  containing  all  those  eleaenta  required  to  acco—odate  the  ealtter-collector  portion  of  a  sensor 
systea.  The  second  zone  la  designated  aa  a  Gap  Zone  which  provides  the  bridge  between  the 
■odulated^eaodulated  signals  and  the  baseband  Inforaatlon  processing  which  Is  turn  will  be  accoaodated 
within  a  third  zone  designated  as  the  Inner  Zone.  The  Zones  In  turn  are  divided  into  seven  Cells  each 
coapoaed  of  specific  Eleaenta  %fhlch  are  specified  in  terms  of  specific  functions.  As  an  example  we 
might  define  and  code  an  HF  Llnk-ll  system  as  composed  of  Zo  (E7C1-4-E3C2+E1  lC3*fE9C4)  -f  Zg(E6C3)  + 
Zl(E14C6't-E3C7).  The  procurement  process  would  be  for  the  development  and  procurement  of  each  Element. 
The  EleiMnt  In  turn  Is  completely  defined  by  an  associated  specification  In  terms  of  function  to  be 
performed*  interface  requirements,  packaging  configuration  and  support  and  operational  software.  As 
illustrated  by  Figure  3  each  Element  (Antenna  -  power  amplifier  -  transmitter  ^  receiver  -  preprocessor 
-  signal  processor  -  data  processor  -  control  -  display)  has  a  specific  task  within  Its  Cell  functioning 
either  as  a  programmable  recooflgurable  device  or  as  a  dedicated  single  Element.  In  any  case  each 
Element  Is  specific  In  its  function  and  when  combined  with  other  required  Elements  will  compose  the 
entire  system  within  an  overall  modular  partitioned  avionics  architecture.  One  can  further  Imagine  the 
color  coding  of  each  physical  Element  associated  with  a  designated  zone  for  purposes  of  Implementation 
and  maintenance  location. 


SYSTEM  INDEX 


Figtire 


Tn  order  for  the  above  concept  to  become  a  reality  two  assumptions  are  made.  First,  the  military 
has  as  an  objective  the  establishment  of  a  common  type  of  avionics  architecture.  Associated  with  this 
assumption  is  that  a  common  avionics  trsnsitionary  architecture  is  in  effect  along  with  a  Doctrine  or 
Policy  %rtiich  provides  guidance  and  direction  to  allow  us  to  evolve  into  the  type  of  architecture  of 
Figure  4.  Secondly,  there  exists  an  approved  standard  Intra-Platform  Interface  Requirements  Document 
(IPIRD).  The  IPIRD  would  govern  implementation  of  networks,  packaging,  and  software  standards. 


With  these  two  assumptions  in  place  and  enforced  we  are  in  a  position  to  take  advantage  of  all  that 
technology  has  to  offer  by  having  the  means  to  exploit  emerging  technologies  on  an  as  come  basis. 
Additionally,  we  can  develop  an  avionics  system  data  base,  based  on  a  common  Avionics  System  Index,  such 
that  once  established  we  can  use  automated  tools  of  CAD  and  simulation  to  construct,  exercise,  and 
assess  an  avionics  system  well  in  advance  of  our  commitment  to  Invest  in  a  complete  system.  We  can 
validate  how  the  system  trill  operate  and  generate  a  number  of  what-if  conditions  to  satisfy  various 
operational  and  degraded  modes  of  operation.  Such  a  situation  allows  us  to  make  our  mistakes  and 
achieve  a  lessons  learned  curve  at  our  desk  top  and  not  st  the  flight  line. 

Also  because  a  system  index  presupposes  a  rigid  description  and  definition  a  specification  can  be 
generated  governing  each  functional  element  placing  the  government  in  a  position  to  generate  procurement 
packages  for  a  specific  technology  appropriate  to  that  Element,  Additionally  by  virture  of  its 
placement  (Cell-Zone)  in  the  avionics  system  such  a  scheme  would  provide  a  valuable  means  of  describing 
functional  domains  which  then  set  the  stage  for  the  introduction  of  expert  systems  and  artificial 
intelligence  operations.  Bounding  of  a  particular  area  of  Interest  allows  for  the  definition  of 
functional  responsibilities  and  interrelationships. 

From  the  viewpoint  of  Expert  Systems  and/or  AI  each  Element  has  In  effect  an  encapsulated  function 
such  that  we  can  concentrate  on  specific  areas  of  applying  AI  technology.  One  very  Important  dependency 
an  AI  Eletsent  will  have  within  a  system  is  that  it  must  have  access  to  a  number  of  Inputs  as  well  as 
being  able  to  disseminate  its  information  to  an  Intercom  via  speech  synthesis  and/or  display  systems  or 
other  processor  for  purposes  of  data  exchange,  consequently  the  need  for  standard  interface  netwrking. 
An  area  for  the  application  of  AI  might  be  for  the  injection  of  natural  language  in  terms  of  the  pilot 


questloQlng  the  statue  and  perforaance  of  his  avionics  and  aircraft  systeas.  In  this  case  an 
alrcraf t/avlonlcs  A1  status  Eleaent  would  be  defined  in  teras  of  what  type  of  "input  knowledge"  would  be 
acquired  (froa  various  on-board  aircraft  sensors  and  avionics  equipaent/systea  built-in-cest ) ,  and  what 
type  of  output  Inforaation  is  requlred4  By  virtue  of  having  a  set  of  interface  standards  the  designer 
of  the  AI  Eleaent  %K>uld  be  in  a  position  to  access  and  foraulate  "source"  data  in  teras  of  what 
inforaation  is  wanted  and  %rhen  it  is  needed.  Llke%rl8e  once  the  AI  processing  algorithas  are  executed 
the  inforaation  can  be  easily  disseainated  to  a  designated  "sink".  Another  area  of  application  might  be 
for  the  identification  and  designation  of  an  external  platfora  detected  by  the  aircraft's  sensor  suite. 
Additionally  once  identified  the  AI  system  could  provide  the  complete  weapons  configuration  and 
performance  characteristics  of  the  potential  enemy  platfora  to  the  pllot/crev.  An  AI  Element  progranned 
as  an  expert  interpreter  would  be  designed  and  implemented  as  a  specific  Eleaent  residing  within  the 
total  system  as  for  example  Z1C6E23. 

Earlier  we  mentioned  the  need  for  a  transitional  architecture  which  would  allow  us  to  evolve  into 
the  projected  architecture  of  Figure  4.  A  transitional  architecture  would  be  implemented  within  upgrade 
and  near-term  (3-7  years)  platforms.  The  transitional  architecture  will  allow  for  the  acceptance  of 
emerging  technologies  by  setting  the  stage  for  their  insertion  as  they  mature  and  become  available. 

There  are  a  number  of  "not  needed  right  now"  provisions,  although  at  least  one  could  be  taken  advantage 
of  in  today's  contemporary  data  bus  implemented  aircraft.  The  HIL-STD-15S3B  data  bus  controller  is 
configured  to  operate  in  two  additional  modes  (inherent  in  1353B  protocol),  the  dynamic  bus  control  and 
broadcast  modes.  Additionally,  two  data  bus  ports  are  incorporated.  The  first  is  for  external  access 
to  the  avionics  system  under  conditions  of  "vrnlght  on  wheels"  for  purposes  of  on-the-deck  and  remote 
station  status  monitoring/maintenance  actions  and  avionics  system  initialization.  This  feature  could  be 
utilized  for  our  contemporary  data-bus  configured  aircraft.  The  second  port  is  for  the  implementation 
of  an  Internal  15S3B  to  high-speed  interface  gateway  for  use  at  a  future  date.  The  next  step  is  to 
seriously  consider  the  MIL-STD-1773,  the  fiber-optic  version  of  15S3B.  We  should  take  avantage  of  the 
benefits  of  a  fiber-optic  transmission  media  within  planned  upgrade  and  near-term  future  aircraft  of  the 
next  3-7  years.  The  transition  to  the  1773  could  be  accomplished  by  initially  performing  the 
electrical-to-optlcal  conversion  at  the  fiber-optic  cable  connection,  not  modifying  each  black-box 
electrical  I/O.  Such  an  approach  would  be  cost  prohibitive.  Future  equipments/elements  would 
Incorporate  the  optical  1773  as  a  basic  I/O  channel.  Likewise,  we  should  consider  the  installation  of  a 
fiber-optic  high-speed  transmission  media  to  accoaaodate  a  future  outer  and  inner  zone  high-speed  data 
bus  configuration.  Once  the  stage  is  set  for  the  Insertion  of  future  technology,  we  can  begin  to  accept 
functional  elements  as  they  become  available.  Iliis  process  is  not  unlike  that  employed  for 
transformation  froa  a  totally  hardwired  system  to  a  hybrid  1353A/B  data  bus  system.  Older  equipments 
retained  their  hard-wired  I/O  and  interfaced  with  13S3A/B  compatible  equipments  via  a  gateway  converter 
box,  designated  as  a  Osmmunication  Control  Set,  a  Switching  Logic  Unit  or  some  such  nomenclature.  In 
either  case,  the  gateway  converter  coupler  is  necessary.  As  time  goes  on  and  a  standard 
optlcal/electrical  interface  I/O  is  adapted  for  a  1553  and/or  future  outer  and  inner  zone  high-speed 
data-bus  system,  the  gateway  converter  will  no  longer  be  required.  A  second  step  taken  for  the 
transition  to  a  contemporary  1553  system  was  the  incorporation  of  a  growth  factor  within  the  bus 
controller.  This  allows  for  the  addition  of  a  number  of  black  boxes  to  be  coupled  directly  to  the  bus 
as  manufacturers  began  to  Incorporate  the  1553  I/O  directly  into  a  particular  equlpatent.  Today,  this  is 
the  rule  rather  than  the  exception. 

Of  equal  Importance  to  the  Incorporation  of  emerging  technologies  Is  thst  we  exploit  the  full 
potentisl  of  each  technology.  In  order  to  illustrate  what  can  be  achieved  within  the  bounds  of  today's 
technology  and  standard  networks  we  shall  cite  two  demonstrations  performed  by  the  Naval  Air  Development 
Center  (NAVAIRDEVCEN).  The  first  was  a  result  of  a  concept  proposed  by  the  NAVAIRDEVCEN  In  1972  to 
demonstrate  the  merits  of  implementing  a  common  aircraft  multiplex  data  bus  system  wlithln  a  network  of 
remote  site  service  and  support  facilities  Figure  6.  In  1978  the  NAVAIRDEVCEN  swarded  a  contract  for 
the  development  of  a  Multiplex  Data  Bus  Test  Set  simllisr  to  the  concept  equipmment  of  Figure  6.  The 
test  set  was  validated  in  the  NAVAIRDEVCEN  LAMPS  HARK  III  and  Basic  Avionics  System  Integration  Concept 
(BASIC)  laboratories.  Subsequenlty  the  Air  Force  contracted  for  a  simflsr  but  ir.nrp  rnmpr^h^nalvp 
equipment  in  1981  from  LORAL  Instrumentation,  San  Diego,  CA.  With  the  cooperation  of  LORAL  and  the 
Naval  Air  Test  Center  (NAVAIRTESTCEN) ,  Patuxent  River,  ND  a  demonstration  of  the  remote  site  service 
support  system  concept  was  conducted  In  June  1983  (2).  An  F-18A  test  aircraft  stationed  at  the 
NAVAIRTESTCEN  was  connected  to  the  LORAL  Test  Sec  SBA-100  equipment  via  the  avionics  1553  internal  data 
bus.  A  second  LORAL  SBA-100  was  located  at  the  NAVAIRDEVCEN,  Warminster,  PA.  The  two  terminals 
interacted  via  RS232  as  a  remote  site  monitor  and  coBsnd  message  injection  source.  An  around  the  world 
service  support  system  la  possible  with  such  a  system. 

The  second  demonstration  combined  the  use  of  emerging  speech  recognition  and  synthesis  technology 
with  the  exploitation  of  the  existing  sviooics  system  architecture  of  the  (^oast  (^rd  HH-65A  helicopter. 
An  avionics  System  "Ask  and  Tell"  (3)  status  information  exchange  was  conducted  via  a  device  designated 
as  an  Aircraft  Speech  Interviewer  (ASl).  The  ASI  was  developed  under  a  contrset  to  NAVAIRDEVCEN  by 
Collins  Avionics  Division,  Odsr  Rapid,  lA.  The  ^I  was  connected  to  the  HH-65A  1553  data  bus  for 
injection  of  voice  cosands  within  the  context  of  the  data  bus  protocol  and  cosand  status  message 
field.  Voice  commands  were  converted  to  data  bus  words  Instructing  selected  equipments  connected  to  the 
bus  to  execute  their  Built-In- Test  (BIT)  routines.  Returning  status  words  were  received  and  converted  to 
speech  via  a  speech  synthesis  module.  An  Interesting  aspect  of  the  "Ask  and  Tell"  demonstration  was  the 
use  of  a  (low  skill)  13  year  old  operator  to  drsmatlcsly  Illustrate  the  advantages  and  utility  which  can 
be  obtained  within  the  context  of  our  existing  systems.  This  demon8trat.:on  was  conducted  at 
Aeroapatiale  Helicopter  Corporation,  Grand  Pralree,  TX  In  September  1982. 
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REMOTE  SITE  SERVICE 


Fiiiure  6 
CONCLUSION 

Emerging;  technologies  together  with  the  need  for  coordinated  operations  of  our  Naval  and  allied 
forces  have  created  the  need  for  standardized  eoiwnunlcatlons  networks  both  within  the  aircraft  avionics 
system  and  for  purposes  of  warfare  area  Interoperability.. 

Avionics  system  engineering  has  become  a  sub-set  of  a  more  broader  warfare  area  engineering  concept. 
Together  the  avionics,  the  platform  and  the  external  warfare  area  environment  make  up  a  total  composite 
such  that  we  must  envision  the  future  and  apply  "the  art  of  a  system'*  In  order  to  bring  each  component 
into  proper  perspective  and  utility. 

In  order  to  facilitate  the  incorporation  of  emerging  technologies  on  an  evolutionary  basis  and  at  an 
affordable  price  we  must  have  an  approved  and  established  policy  in  the  form  of  an  Intra-Platform 
Interface  Requirement  Document  which  articulates  aircraft  network  connectivity,  packaging,  software  and 
support  standards. 

Lastly  we  must  set  the  stage  for  maturing  technologies  by  incorporating  a  transltlonary  avionics 
architecture  which  will  allow  for  the  implementation  of  emerging  technologies  as  well  as  the 
exploitation  of  the  full  potential  of  each  technology  in  terms  of  expanding  its  utility. 
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DISCUSSION 


P.Flahault,  FR 

(1)  Does  a  MIL-STD-1553-2  exist? 

(2)  Notice  2  discusses  communications  means  and  recommends  that  the  broadcast  mode  not  be  used.  Please  address 
this  issue. 

Aulhor*s  Reply 

(1)  No,  there  are  no  plans  to  issue  a  MIL-STD-1553-2. The  version  issued  in  1^78  is  the  DOD  (tri-service)  verston  of 
record. 

(2)  Notice  2  does  not  “delete”  the  broadcast  mode  from  the  basic  MIL-STD- 1 553B.  Currently,  there  is  much 
discussion  within  the  tri-service/'TJATO/industry  avionics  community  |c.g..  Society  of  Automotive  Engineers 
(SAE-AE9  Subcommittee)!  on  the  merits  of  the  broadcast  mode.  To  date,  tc  my  knowledge.  thi.s  mode  is  still 
inherent  in  the  existing  MIL-STD- 1 553B. 


E  J.Manzie,  CA 

To  clarify  a  point  regarding  MIL-STD- 1 553B.  a  Notice  2  to  this  standard  exists.  This  notice  addresses  the  broadcast 
mode  and  suggests  it  not  be  used. 

Author's  Reply 

It  is  true  that  Notice  2  suggests  the  nonuse  of  the  broadcast  mode.  However,  the  entire  DOD  (i.e..  the  Army  and  Navy  ) 
has  not  approved  Notice  2;  only  the  Air  Force  has  suggested  the  nonuse  of  the  broadcast  mode. 
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SUMMARY 


To-day,  in  military  aircraft  systems,  each  externa)  sensor  (radar,  ESM,  electro- 
optical  equipment,  radiocommunications)  is  almost  independent  and  reports  directly 
to  the  central  computer. 

Taking  into  account  first  the  evolution  of  operational  context  in  which  the  aircraft 
is  involved  (increasingly  varied  and  quantitative  nature  of  the  threat)  and  second 
the  dramatic  progress  in  processing  capabilities  (growth  of  several  orders  of  magni¬ 
tude  in  the  same  volume  between  1980  and  1995)  it  appears  necessary  and  possible  to 
spread  the  ‘'Intelligence"  aspects  of  the  weapon  system  in  order  to  optimize  the 
global  cost-efficiency. 

This  distribution  enables  each  specialist  to  concentrate  his  efforts,  in  order  to 
take  advantage  of  the  ever  increasing  scope  of  knowledge  associated  with  each 
discipline. 

When  considering  an  individual  sensor,  an  expert  system  allows  pseudo  real  time 
processing,  taking  into  account  simultaneously  the  characteristics  of  the  environ¬ 
ment  and  specific  mission  requirements.  This  is  the  high  technology  province  of 
experts  in  physics  and  mathematics. 

When  considering  whole  set  of  expert  system  aliows  intelligent  data 

fusion.  This  is  once  again  the  province  of  sensor  technicians  involving  in  addition 
operational  aspects. 

In  the  case  of  the  whole  aircraft  weapon  system,  expert  systems  allow  optimal  control 
of  the  mission,  taking  into  account  the  predetermined  data  and  their  updating  in  real 
time  (tactical  situation  assessment,  aircraft  status,  weapon  status,  mission  planning 
man-machine  interface,  ..,).  This  is  within  the  scope  of  operational  and  mission 
managers,  considering  human  capacities  in  environments  of  particular  stress. 

In  this  paper,  the  sensors  subsystem  is  dealt  with,  its  architecture  is  defined  and 
its  function  in  the  aircraft  weapon  systefh  is  described. 


KEYWORDS 

Expert  system,  sensor  fusion,  external  sensors,  aircraft  weapon  system. 

1  .  I ntroouct  ion 


To-day,  in  military  aircraft  systems,  each  external  sensor  (radar,  ESM,  electro- 
optical  equipment,  radiocommunications)  is  almost  independent  and  reports  directly 
to  the  central  computer. 

Taking  into  account  first  the  evolution  of  the  operational  context  in  which  the 
aircraft  is  involved  { i ncreas i ngly  varied  and  quantitative  nature  of  the  threat) 
and  second  the  dramatic  progress  in  processing  capabilities  (growth  of  several 
orders  of  magnitude  in  the  same  volume  between  1980  and  1995)  It  appears  necessary 
and  possible  to  spread  the  ''Intelligence"  aspects  of  the  weapon  system  in  order  to 
optimize  the  global  cost-efficiency. 

When  considering  and  individual  sensor,  an  expert  system  allows  pseudo  real  time 
processing,  taking  into  account  simultaneously  the  characteristics  of  t)ie  environ¬ 
ment  and  specific  mission  requirements. 

When  considering  the  whole  set  of  sensors,  an  expert  system  allows  intelligent 
data  fusion. 

In  the  case  of  the  whole  aircraft  weapon  system,  expert  systems  allows  optimal 
control  of  the  mission,  taking  into  account  the  predetermined  data  and  their 
updating  In  real  time  (tactical  situation  assessment,  aircraft  status,  weapon 
status,  mission  planning,  man-machine  interface,  ...). 

In  this  n»per,  the  sensors  subsystem  is  dealt  with,  its  architecture  is  defined 
and  its  function  in  the  aircraft  weapon  system  is  described. 
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2.  ^^reuIctablE  Global  architectuhe 

Many  papers  have  already  presented  various  architecture  wiiicn  could  De  propused 
fur  future  military  aircraft. 

Among  tne  most  significant,  we  nave  retained  tne  architecture  proposea  in  tne 
DARPA  project,  tne  PILOT'S  ASSOCIATE  Z'j- 

'ne  general  diagram  of  tne  PILOT’S  ASSOCIATE  is  shown  on  figure  1. 

In  tnis  diagram,  tne  ■' o  1  ac  k.  -  OOx ''  named  “sensor  fusion  is  a  i  ey  element  of  the 
operational  situation  assessment  in  real  time.  As  a  matter  of  ^act,  it  is  the 
relevance  of  tne  information  issued  from  tnis  Dlack-oox'  whicn  provides  the 
pilot  with,  the  necessary  decision  factors  to  ensure  tne  success  ot  nis  mission 
and  his  Own  survivability.  Ronald  M.  Yannone  121  discusses,  in  nis  article, 
tne  roie  of  this  "sense'*  subsystem"  and  its  close  relationship  wiin  the  '.jLiicdl 
situation  assessment  subsystem. 

'nis  type  of  architecture  seems  to  us  to  fit  in  very  well  w  1 1  n  i  •'  L.e  capabilities 
of  the  different  “dctors”  involved  in  the  design  an  development  of  an  overall 
aircraft  weapon  system. 

’^ne  various  external  sensors  considered  in  future  military  aircraft  (radar.  ESM. 

€  1 ec t r 0  -  op 1 1  c a  1  equipment,  r ad i ocommun i c a 1 1 on  $ ,  have  each  their  own 

specific  c n a r ac t er 1 s t 1 c s  and  the  men  in  charge  of  these  equipments  must  be  very 
highly  specialised  in  tneir  respective  fields. 

At  the  other  end,  the  man  in  charge  of  the  whole  aircraft  weapon  system,  must 
be  a  specialist  in  operatioi'dl  and  mission  manager  problems. 

’o  prevent  overload  and  therefore  inefficiency,  the  pilot  can  only  take  into 
account  Synthetic  information,  cleared  of  tneir  fluctuations,  their  uncertain!* 
ties  and  sometimes  their  contradictions. 

Due  to  the  great  variety  of  information  issued  by  the  sensors,  and  their  possible 
complementarity,  it  appears  necessary  to  achieve  a  "smart"  fusion,  in  order  to 
improve  them  and  to  solve  the  conflicts  which  might  occur. 

The  respons to i 1 1 t y  for  this  “smart"  fusion  can  only  be  assumed  m  an  efficient 
way  by  the  men  w^o  hjvc  .cr_,  tCvhnical  knowledge  cf  the  different 

sensors.  They  must  also  have  a  fair  knowledge  of  operational  problems  in  the 
avionics  field. 

It's  only  with  this  combined  proficiency  that  they  will  be  able  to  solve,  for 
instance,  the  identification  conflict  in  which  an  "error"  of  a  sensor  can  be 
due  to  a  kind  of  counter-measure  from  the  enemy. 


3.  DESCRIPTION  OF  THE  SENSOR  SUBSYSTEM 


At  the  date  we  are  considering,  i.e.  the  years  2000*,  the  external  sensors 
equipping  a  sophisticated  military  aircraft  will  be  the  following  ones  . 

•  a  radar  for  detection  in  the  frontal  zone  (at  least  a  cone  of  120  )  with  an 
IFF  i nterrogator  , 

-  a  passive  detector  of  radio  and  radar  signals  (ESM)  covering  any  di*-ectinn, 

1  4  7x  s  t  e  r  a  d  i  a  n  s  ) 

-  a  passive  and  active  (Lidar)  el ec t ro*opt i c a  1  system,  covering  any  direction. 

-  a  multifunction  communication  system  such  as  the  SINTAC  (French  equivalent 
of  JT IDS) . 

These  "sensors"  will  include  very  sophisticated  data  processing,  including 
expert  systems,  in  order  on  one  hand  to  optimize  their  own  functioning  in  the 
real  environment,  taking  into  account  the  initial  constraints  (type  of  mission, 
discretion,  ...)  and  on  the  other  hand  to  perform  a  certain  level  of  ide’‘*ifi- 
cation  on  the  detectea  targets  (for  instance,  Doppler  lines  of  aircraft  engines 
"seen"  by  the  radar,  identification  of  a  given  terrain  following  radar  by  the 
E.S.M,,  significant  loads  of  missiles  under  »n  aircraft  "seen"  by  the  E.O. 
system,  . . .  ) . 


A  good  example  of  this  identification  function  is  given  Oy  Thierry  SCHAN6  in  C3D • 
The  sensors  will  provide  two  types  of  information  : 

-  numerical  data,  with  a  quality  factor  (<yi . 

'  symbolic  data,  with  a  confidence  factor  (C) 

Table  2  summarize  the  information  provided  by  each  sensor. 

The  essential  characteristics  which  appear  when  examining  those  data  are  the 
following  ones  : 

-  They  are  not  simultaneous  {different  rate)  nor  are  they  all  present  (difference 
in  detection  range,  for  instance  ;  ESH  200  km.  Radar  100  km,  E.O.  20  km  in  a 
given  situation,  . .  . ) . 

-  Their  avalability  depends  on  the  type  of  sensor  (ESM  generally  provides  neither 
radial  velocity  nor  range),  and  on  the  jamming  environment. 

-  They  do  not  have  the  same  accuracy. 

•  They  are  not  all  reliable  (use  of  decoy  by  enemy). 

Therefore  the  interest  of  a  "smart"  fusion  is  evident  in  order  to  improve  the 
accuracy  and  the  reliability  of  the  information  (especially  in  presence  of 
counter-measures } . 


The  block  diagram  of  the  fusion  system  which  could  be  realized  is  given  in 
f i gure  3  . 

The  numerical  data  INUM)  from  each  sensor  will  generally  be  provided  to  the  system 
only  after  filtering  or  tracking  in  order  to  increase  their  quality. 

The  symbolic  data  (SYMB)  delivered  by  their  internal  expert  systems  will  be 
refreshed  in  quasi  real  time. 


The  overall  data  coming  from  eacA  sensor  enter  a  processor  allowing  their 
temporal  and  spatial  alignment  Q. 

The  numerical  data  are  then  sent  to  a  proximity  estimator  (2)  in  order  to  obtain 
an  initial  spatial  correlation. 

The  so-aefined  "sets"  are  then  sent  to  an  expert  system  which  w’li  take  into 

account  symbolic  data  to  effect  an  evaluation  of  coherence,  "^he  result  could  be 
a  rejection  of  the  proposed  correlations  and  possibly  new  proposals. 

The  dialogue  will  converge  on  the  generation  of  identified  "tracks"  with 
acertain  level  of  confidence  (C).  These  tracks  will  be  continuously  maintained 
(5)  in  order  to  : 

•  to  confirm  and  improve. 


-  cancell  or  reject  (too  old  or  level  of  confidence  too  low), 

-  propose  new  tracks  to  the  processor  2). 

For  each  detected  target,  the  "track"  to  be  carried  out  will  consist  of  the 
following  information  (with  their  quality  or  confidence  factor) 

-  Status  vector  X,  Y,  Z.  X  ,  Y  ,  Z. 


-  Range 

-  Radial  velocity  and  time-to-go  before  direct  threat  (according  to  criteria) 

-  "Smart"  identification  (i.e.  MIRAGE  III  E  ♦  weapons  A,  B.  C, 


-  Threat  data,  for  example 


.  detection  probability  by  "his”  radar, 

.  probability  of  triggering  "his"  weapons  (lock-on  range,  shooting  range'. 

These  data  are  then  sent  to  the  tactical  situation  assessment  Expert  system, 
in  order  to  enter  the  whole  "Pilot’s  Associate". 
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4.  CONCLUSION 


Highly  decen t r a  1 i zed  and  adaptable  a v i on t cs sy s terns  are  the  only  way  to  effecti¬ 
vely  counter  the  ever  increasing  complexity  of  weapon  system 

-  decentralization  facilitates  the  dra^inq  up  of  module  spec i f i c a i i on s  and 
therefore  their  test  and  validation, 

-  flexibility,  made  possible  by  the  Artificial  Intelligence  approach,  allots 
updating  of  complex  systems  with  minimum  maintenance  of  embedded  software. 

A  lot  of  work  remains  to  be  done  to  build  a  completeand  efficient  electronic 
pilot's  assistant.  In  addition  close  cooperation  between  the  different  Experts 
of  the  overall  system  is  necessary 

-  Experts  on  the  different  sensor  aspects  who  have  to  provide  pertinent  informa¬ 
tion  from  the  outside  world. 

-  Expert  on  sensor  fusion,  who  must  take  into  account  sensors  capabilities  on 
one  hand,  and  operational  problems  on  the  other  hand. 

-  Expert  on  overall  aircraft  aspects  who  must  take  into  account  all  tne  mission 
constraints  and  the  human  pilot's  capabilities. 

The  winner  of  the  aggressive  competition  in  the  military  avionic  market  will 
certainly  be  the  country  that  will  achieve  both  a  friendly  and  interactive 
cooperation  between  the  different  companies  involved  in  the  design  of  the 
future  systems. 
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DISCl’SSION 


W.R.Fried,  US 

( I )  Will  the  French  data  system  you  mentioned  be  compatible  with  the  US  JTIDS  <e.g..  modulation  and  message 
formal)? 

t?)  l>Hjs  the  planned  processing  include  automatic  correlation  of  FSM -derived  (INTHl.)  target  tracks  and  radar- 
derived  target  tracks? 

Authors  Reply 

( 1 )  Yes,  the  Systeme  d'ldenlification.  dc  Navigation,  de  C'ontnilc  dc  Trafic.  d'AniicolIision.  et  de  Communication 
(SINTAC)  IS  fully  compatible  and  interoperable  with  JTIDS  TDMA  and  has  the  same  modulation  and  message 
formats  (i.e..  Link  16  TADIL  Jj. 

(2)  Yes.  the  system  includes  HSM  tracks  and  radar  tracks  correlation. 


E.Cambise,  IT 

( 1 )  What  IS  the  time  frame  of  the  iniplementaiion  i>f  ihe  priiposed  architecture? 

<2)  What  are  the  hardware  requirements  for  processing  power  and  memory  to  support  the  implementation 

Author's  Reply 

.As  mentionetl.  we  are  m  a  preliminary'  study  phase.  It  implies  that. 

\  \ )  I'hc  architecture  will  not  he  implemented  <»n  the  ne.xt-gcnerati<»n  aircraft,  hut  on  the  nc.xi  2(HM)  year  generation 

( 2  I  Processing  power  and  inem<iry  requirements  are  not  yet  defined,  hut  wc  esiimafc  ihai  thev  will  be  at  a  \er\  high 
lescl.  aehies able  only  with  the  most  advanced  VHSK'  products. 


K.fiuiol.  f  k 

>  a  I  II  une  appluabilile  pour  lesavionsde  la  perimlc  — ’ 

Reptinse  d'.Autcur 

II  \  a  en  elude,  sans  beaucoup  srinlelligcncc  artifieielle.  uncouplagc  radar- mtrarouge 
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RAPID  PROTOTYPIMG  OF  COMPLEX  AVIONIC 
SYSTEM  ARCHITECTURES 
by 

L.  B«rardl,  N.  Giorsi,  W.  Mellano,  A.  Valente,  E.  Zuceo 

Aerltalia  -  Grupoo  Slataal  Avlonlcl  ad  EquipagglaiMntl 
10072  Caaalla  (Torino)  -  Italy 


Si—ary 


Thla  paper  deacribea  a  deaign  tool  celled  ECATE  (Expert  Conaultant  for  Avlontca  Syatea  Tranaformatlon 
Exploitation)  developed  by  the  Avlonlca  Syatea  and  Equipment  Croup  of  Aerltalia. 

ECATE,  rapidly  prototyping  different  altematlvea,  helpa  the  designer  In  establishing  the  Information 
flow  architecture  of  the  avionics  system,  that  Is  the  organization  of  the  Internal  data  handling.  The 
tool  provides  the  uaer  with  an  Interface  to  aaalat  him  In  describing  the  avionics  from  the  point  of  view 
of  the  data  handling,  and  presents  the  results  In  a  suitable  format;  It  performs  consistency  checks  and 
advices  the  uaer  on  possible  architectural  problems  by  means  of  the  expert  system  techniques. 

The  paper  contelns  aleo  mama  Indications  on  the  development  environment  of  the  tool  and  how  It  works  In 
a  consulting  session.  Some  exsmples  give  an  Idea  of  the  result  that  can  be  obtained. 

Conclusion  Is  that  not  only  the  tool  Is  valuable  for  the  Information  flow  architecture  deaign  but  also 
It  shows  that  the  use  of  the  knowledge  engineering  and  the  Artificial  Intelligence  techniques  can  be 
effective  to  meat  the  problems  arising  when  complex  systems,  not  only  avionics,  are  Involved, 

1.  Introduction 

A  state-of-the-art  avionics  system  shall  be  fully  Integrated  with  the  other  systems  of  the  aircraft 
and  shall  take  full  advantage  from  the  features  of  the  microelectronics,  to  provide  the  crew  with  the 
highest  mission  success  probability. 

It  means  to  find  a  real  Implementation  for  concept  like  distributed  processing,  sensor  data  fusion, 
adaptive  reconfiguration,  expert  pilot  assistant,  synthetic  world  displaying,  now  made  possible  by  the 
advancemement  of  the  technology,  apecially  the  data  processing  and  transmission. 

But  in  such  a  system  the  performance  Increase  Is  not  simply  due  to  the  higher  performances  of  the 
microcircuits,  on  the  contrary  it  derives  prlmarly  by  an  increase  of  the  overall  system  complexity. 

In  fact  the  "black  box",  a  large  unit  with  well  defined  Interface  and  function  allocation.  Is  no  more 
the  basis  for  the  advanced  system  design  but  is  being  substituted  by  lower  seals  units,  which  changing 
combinations  provides  the  best  adptatlon  of  the  system  to  a  changing  environment. 

It  Is  difficult  to  establlch  a  metric  for  the  system  complexity  (see  for  example  ref.  1),  however  It 
could  be  said  that  It  la  rsflscted  by  the  amount  of  memory  used  for  operational  software  storage,  which 
today  Is  Increasing  to  a  rate  at  least  an  order  of  magnitude  higher  than  the  number  of  other 
microcircuits  In  an  avionics  system. 

The  Increasing  complexity,  while  can  allow  for  dramatic  Improvements  In  terms  of  reduced  pilot  workload 
and  mission  success  probability,  hae  also  some  Important  drawback. 

It  Is  evident  that  a  complexity  which  la  mainly  software  Implies  a  design,  development  and  testing 
process  and  a  management  of  It  much  more  difficult  than  In  a  conventional  system. 

Therefore  some  change  to  the  way  of  thinking,  the  tools  and  the  organization  of  the  Industry  are 
necessary. 

It  Is  our  opinion  that  the  tools  and  techniques  of  the  Artificial  Intslllgsnce  can  be  effectively 
applied  not  only  In  the  system  Itself,  but  also  to  manage  Its  complexity  for  the  people  who  shall  design 
It. 

Scope  of  this  paper  Is  to  Illustrate  an  application  of  the  rapid  prototyping  and  expert  aystem 
techniques  to  the  design  of  the  data  flow  organization  within  a  complex  avionics  system. 

2.  The  problem  of  the  system  architecture 

The  problem  eonesms  the  aatabliahlng  of  a  correct  data  flow  archltaeturs.  Thera  are  several 
Interpretation  of  the  term  "arehltacture"  In  the  avionic  syatsm  design;  it  can  be  applied  to  the 
physical  structure,  the  topology,  the  software  organization  and  ao  on.  All  these  are  aapacts  of  the  aWM 
charactsrtstle,  the  way  In  which  the  system  components  are  organised  and  work  together  in  order  to 
create  a  system. 

The  architectural  aspect  choaen  for  the  application  described  In  this  paper  la  the  Information  handling 
within  the  avionics,  l.e.  the  characteristics  of  the  data  flow  and  processing  among  the  various  kystem 
components,  considered  from  the  point  of  view  of  the  Information  treatment. 

Therefore  the  following  definition  of  architecture  will  be  usued  In  the  following  paragraphs; 
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Definition 

System  architecture  is  the  organization  of  the  Information  generation,  distribution,  processing  and 
utilization  within  the  boundaries  of  the  avionics  system. 

A  pictorial  view  of  the  above  definition  Is  given  in  fig.  2-1. 

The  boundaries  of  the  avionics  system  are  Intended  to  define  the  meaning  of  generation  and  utilization 
of  the  Information. 

In  other  words  If  the  boundary  Identifies  the  world  outside  the  aircraft  all  information  coning  from  It 
corresponds  to  a  generation  of  Information  for  Uta  avionics  system;  on  the  other  side  the  data  are 
utilized  when  they  are  provided  to  the  crew  via  a  display  or  to  the  external  world  via  an  antenna. 

Such  an  architecture  Is  relatively  easy  to  describe  by  means  of  few  building  blocks  with  a  limited 
number  of  peculiar  characteristics;  but  a  correct  design  of  it  has  relevant  influence  on  the  overall 
performance  of  the  system,  because  it  Is  usually  established  In  the  very  early  stages  of  the  design  and 
It  Is  dlfflcut  to  be  drastically  changed  during  the  development  process. 

Therefore  it  is  clear  that  a  serious  error  In  the  data  flow  architecture  design  impairs  the  achievement 
of  the  design  objectives  in  terms  of  time,  coat  and  performance. 

For  that  reiason  the  architecture  of  the  avionics  aystem  la  usually  designed  by  highly  experienced  people 
with  support  of  the  operations  research  tools  (see  ref.  2):  nevertheless  the  work  of  these  people  is 
difficult  to  quantify  and  to  describe  analltically ,  being  often  result  of  empirical  knowledge  and 
heuristics. 

When  the  complexity  grows  the  difficulty  of  the  design  task  dramatically  increases  to  a  level  that  the 
problem  shall  be  partitioned  Into  simpler  problems,  loosing  part  of  the  efficiency  achieved  by  an 
overall  view. 

An  alternative  that  can  help  to  still  consider  the  problem  from  a  global  point  of  view  keeping  to  a 
reasonsable  level  the  complexity  managed  by  the  designer.  Is  to  take  advantage  by  the  Artificial 
Intelligence  tools  and  techniques,  prepared  to  describe  and  process  complex  situations  with  an  heuristic 
approach  to  the  problem,  l.e.  rapid  prototyping  and  expert  systems. 

Rapid  prototyping  of  a  complex  architecture  helps  to  easily  evaluate  many  alternatives  while  an  expert 
system  directs  the  search  for  the  best  design.  A  dedicated  tool  combining  together  the  two  techniques 
can  organize  and  manage  the  overall  complexity  of  an  architecture,  requiring  from  the  operator  higher 
level  decisions  only. 

A  tool  like  that  sketched  above,  described  in  the  following  paragraphs  and  developed  In  our  laboratory, 
can  be  of  effective  use  for  the  purpose  and  can  demonstrate  the  advantage  of  the  Artificial  Intelligence 
approach  In  the  design  of  complex  avionics  systems. 


3.  Theorstlcal  considerations 
3.1.  System  description 

The  building  blocks  that  shall  be  used  for  the  construction  of  an  object  oriented  data  flow 
architecture  have  characteristics  that  describe  mainly  their  attitude  with  respect  to  the  Information 
handling. 

Four  types  of  objects  represent  the  building  blocks. 


1.  Generators ,  the  sensors  of  the  system,  the  controls  available  to  the  crew  and  the  Interface  to 

other  systems. 

2.  Processors,  signal  processors,  mainly  associated  with  sensors  and  displays  and  data  processors  to 

elaborate  Information  at  an  higher  level. 


3.  Utilizers,  displays  for  the  crew.  Interfaces  to  other  systems,  emitters  or  weapon  which  stimulate 
the  external  world. 


4.  Channels  transmission  means  that  link  together  all  above  objects  when  not  directly  Interfaced 

(aggregation  of  objects). 

The  table  3-1  lists  an  example  of  the  typical  characteristics  aesoeiated  to  the  objects. 

It  shall  be  pointed  out  that  the  eharacteristlcs  may  vary  In  relation  with  some  peculiarities  of  the 
described  system. 

The  proesasors  and  the  channels  are  possibly  multiport  devices,  while  equipment  like  a  menoststlc  radar 
may  be  described  by  a  signal  processor,  a  generator  and  an  utilizer,  that  is  an  aggregation  of  objects. 
Although  not  directly  related  to  a  technological  solution,  the  objects  that  form  a  system  architecture 
from  the  point  of  view  of  the  Information  handling,  shall  nevertheless  take  Into  account  the 

state-of-the-art  to  avoid  a  design  perfect  but  not  feasible. 


The  building  blocks  shall  be  combined  to  form  the  information  handling  architecture  corresponding  to  the 
functional  architecture  to  model. 

The  architecture  is  characterized  by  some  features,  system  descriptors  which  are  listed  in  table  3-2. 
Some  descriptors  need  explanation  on  its  definition,  while  the  calculation  methods  are  embedded  into  the 
tools  and  will  oe  described  in  para.  3. 

Risk  The  development  risk  take  into  account  how  much  each  object  is  close  to  its  technological  limit 
and  how  the  the  combination  of  objects  influence  the  development. 

Integration  level  It  takes  into  account  how  good  is  the  processing  within  the  system.  An  higbier 
integration  level  is  a  merit. 

Growth  Capability  Represents  the  dual  of  the  resource  utilization  of  processors  and  channels. 

It  shall  be  noted  that  the  descriptors  can  be  computed  also  for  a  limited  portion  of  t.he  system,  a 
subsystem. 

3.2.  Rapid  prototyping  and  expert  system  design 

A  rapi  i  prototyping  tool  shall  assist  the  user  to  convert  from  the  functional /performance  requirement.-; 
to  a  descriptio*!  that  uses  the  object  and  connections  illustrated  in  para.  3.1. 

But  an  easy  means  to  prototype  many  alternate  design  solutions  is  not  sufficient  because  the  l-.n'^wledge 
behind  the  architectural  design  is  not  totally  convieed  by  analytical  descriptors. 

Therefore  an  expert  system,  a  tool  that  allow  to  acquire,  use,  modify  and  make  available  a  type  of 
knowledge  which  is  complex,  difficult  to  transfer,  empiric,  incomplete  and  heritage  of  a  limited  number 
of  people  is  the  most  appropriate  supplement  for  the  rapid  prototyping  tool . 

The  expert  system  shall  direct  the  search  for  a  better  architecture  and  provide  advice  on  solution  that 
may  also  not  have  different  descriptor  values  but  are  known  to  guarantee  an  higher  confidence  of 
success . 

The  operational  flow  of  an  architectural  design  carried  out  by  means  of  a  rapid  prototyping  expert 
system  is  skectched  in  fig.  3-1. 

4.  The  tool,  ECATE 
4.1.  The  environment 

The  tool.  foreseen  by  para.  3.2  and  called  cCATE,  (Expert  Consultant  for  Avionics  system 
Transformation  Exploitation),  has  been  developed  by  means  of  KEE  (Knowledge  Engineering  Environment,  TM 
by  Intel  1 icorp) ,  running  on  a  dedicated  LISF  workstation  (EXPLORER.  TM  by  Texas  Instruments). 

KEE  is  a  development  environment  prepared  for  Expert  System  construction,  it  could  be  cnt.sidered  an 
hybrid  tool  built  on  a  range  of  state-of-the-Art  Artificial  Intelligence  techniques  utilized  to  combine 
different  type  of  knowledge. 

The  knowledge  is  organized  in  frame/units  associated  to  which  are  their  peculiar  oharac teri  st  ics ,  that 
structure  is  particularly  suitable  for  the  description  of  our  problem  because  it  implemet.ts  a 
programming  oriented  to  object  linked  by  relations. 

Bv  means  of  KEE  it  has  been  icr.plemented  the  following; 

1.  The  user  interface 

2.  The  collection  of  objects  and  relations  that  represent  the  system 

3.  The  algorithms  and  procedures  for  the  descriptors  computation 

4.  The  expert  knowledge 

5.  The  knowledge  handling  structure. 

The  knowledge  about  the  system  is  acquired  via  a  graphic  interface  and  processed  by  the  inference 
mechanisms  embedded  in  the  KEE  environment,  according  to  the  sc-c  of  rules  describing  the  expert 
knowledge . 


4.2.  The  structure 

The  structure  of  the  tod  can  be  described  by  means  cf  the  block  diagram  sl-.own  in  fig.  4-1. 
Hereafter  follows  a  brief  description  of  the  main  components  of  the  structure. 
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User  Interface  The  user  interface  assists  the  user  to  represent  his  system  in  accordance  with 
convention  of  the  formal  description  and  is  formed  by: 

a)  graphic  utilities  using  icons,  representing  the  objects,  with  associated  menus  for 
describing  their  characteristics. 

b)  indicators  of  the  system  descriptors  of  the  terminated  system. 

c)  menu  sensitive  “pushbuttons”,  i.e.  means  to  activate  a  “method''  (see  below). 

Methods  The  methods  are  procedures  codified  in  LISF  to  execute  algorithms,  object  interaction  and 
reasoning/control  stategies  (see  table  4-1  for  example  of  methods). 

Permanent  data  base  It  contairis  the  description  of  the  fouj-  types  of  c/bjects  and  their  classes  . 

It  contains,  moreover  the  expert  system  rule  base,  unmodifiable  by  the  user. 

Working  area  It.  is  formed  by  the  units,  which  characteristics,  called  “slots",  uescribe  a'll 

information  about  the  system  under  development. 

Inference  structure  This  stiucture  is  formed  by  an  inference  engine  operating  on  the  rules. 

The  structure  and  the  development  environment  allow  for  the  maximum  flexibility;  to  change  the  object 
and  system  descriptors,  inference  rules  or  methods  is  extremely  easy  for  the  expert  system  designer. 
That  feature  is  of  capital  importance  and  is  used  currently  because  the  t(H)l  shall  evolve  with  tlie 
knowledge  available. 

4.3.  Consulting  EOATE 

The  steps  of  a  consulting  session  are  summarized  in  fig.  4-2  and  briefly  explained  hereafter. 

Configuration  Insertion  The  user.  with  assistance  of  the  tool  graphic  facilities  inserts  the 

configuration  of  objects,  aggr«*gat ions  and  relations  ne  wants  to  prototype  (see 
for  example  fig.  4-3). 

Compat  ibi  1  t  t.y  ■.  er  i  f  icat  1  on  The  ’ool  verifies  after  each  input  it^s  compatibility  with  the  obierts 
related  to  it . 


Overal  1  Compat  ibi  ]  i  >.y  When  the  configuration  is  eomplet.e  the  activa^ifin  of  the  "terminated  system" 
push-button  star*-s  a  verification  of  the  overall  architecture  compatibility. 

The  results  of  ttie  step  above  can  be; 

1.  Request  for  more  i  nfornat  i.)n  i  for  example  some  relation  is  la'ki.ng  or  some  data  are  not  available^ 

2.  Display  of  incompatibility  warnings  at  sys*em  level  (for  example  a  multipoint  channel  of 
insufficient  capacity). 

3 .  Sat isfac tory  compat ibi I i ty 


Descriptors  computation  When  the  system  compatibility  is  not  violated  a  method  is  activated  to  compute 
all  system  descriptors  for  which  sufficient  information  is  available. 

Result  display  The  results  of  the  previous  step  can  be  displayed  (see  fig.  4-4}  in  either  the 

numerical  or  hystogram  format. 


Optimization  ECATt.  by  means  of  rules  activated  in  forward  chaining  inference  presents  to 

the  user  advices  on  possible  architecture  problems  and  suggested  changes 
involving  objects,  aggregations,  subsets  or  the  overall  system. 


Assistance  request  The  use  ran  ask  for  assistance  in  optimizing  the  architecture,  giving,  if  he 

wish,  instruction  on  the  direction  of  the  optimization. 

Configuration  change  In  case  the  user  wants  to  follow  one  or  more  of  the  devices  he  can,  by  means  of 
a  pushbutton,  modify  the  configuration  and  restart  the  consulting. 


Explanation 


The  user  can  ask  at  any  time  information  about  the  facts  that  have  activated 
the  rules  and  generated  the  advices. 
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The  tool  accepts  at  any  step  not  only  numerical  values  in  response  to  its  queries  but  also  generic 
indications,  like  high,  low  etc. 

The  consulting  session  rar.  be  terminated  at  any  time  and  the  results  saved  in  the  library. 

4.4.  Validation 

The  validation  of  a  tool  like  ECATE  shall  answer  to  two  kind  of  questions: 

a)  Is  the  tool  conform  to  its  specification? 

b)  Is  the  tool  suitable  for  its  purpose? 

For  the  first  check  ECATE  has  been  submitted  for  evaluation  to  the  experts  who  concurred  in  its 
development  and  to  foreign  experts,  exercizing  it  by  means  of  test  cases. 

The  second  check  is  much  more  difficult  to  perform,  because  it  is  supposed  to  require  a  demonstration  of 
the  development  of  different  architectures,  accepted  or  rejected  by  ECATE. 

The  validation  is  still  in  progress,  but  the  results  available,  related  to  the  first  check,  show  a  good 
agreement  with  the  predictions. 

Nevertheless  it  shall  be  pointed  out  that  the  high  flexibility  allowed  by  the  development  environment 
and  the  tool  structure  stimulate  a  continuous  refinement  to  adapt  ECATE  to  new  situations  or  to  increase 
its  knowledge.  It  is  in  fact  current  practice  to  introduce  new  object  descriptors,  computing  methods  or 
inference  rules. 

Therefore  also  the  validation  is  continuing  to  follow  tne  evaluation  of  ECATE  and  will  not  give  final 
results  until  the  refinement  work  is  completed* 


5.  Examples 


5.1.  A  simple  system 

In  this  paragraph  it  is  shown  an  example  of  a  simple  architecture  to  illustrate  how  the  system 
works . 

Fig.  5-1  shows  how  the  tool  allows  to  represent  the  sketch  of  the  system  prepared  by  the  designer,  while 
fig.  5-2  shows  how  the  entire  system  architecture  looks  like  and  comprise  some  advices  given  by  the 
expert  system. 

5.2.  A  more  complex  system 

A  state-of-the-art  system  with  complex  architecture  is  shown  in  fig.  b-3,  already  in  the  formalized 
description  of  ECATE. 

5.3  A  Future  avionics  system 

At  the  moment  we  believe  that  the  knowledge  available  on  future  avionics  system 

architecture,  (see  ref.  3),  is  not  sufficient  to  effectively  use  ECATE. 

Reason  is  mainly  because,  although  enough  data  on  sensors  and  processors  can  be  found,  the  knowledge 
lacks  in  the  display  and  control  area  and  specially  on  standardized  multipoint  channels,  switch, 

backplane  and  high  speed  data  bus.  Insufficient  Is  also  the  knowledge  of  the  rules  that  regulates  the 
overall  system  functioning. 

Nevertheless  data  are  gathered  and  trials  are  performed  with  reference  to  experimental  data  to  allow  the 
specific  ECATE  knowledge  to  improve. 


6.  Concluaions 


The  scope  of  ECATE,  an  architectural  design  tool  conceived  and  realized  by  Aeritalia,  Avionic 
Systems  and  Equipment  Group,  in  twofold. 

First,  it  shall  provide  valuable  means  to  design  the  information  handling  architecture  of  an  avionics 
system,  that  is  a  rapid  prototyping  expert  system,  which  make  available  a  knowledge  difficult  to  acquire 
and  transfer  and  often  heuristic. 

Second,  it  shall  demonstrate  the  effectiveness  of  the  Artificial  Intel ligenc  tools  and  techniques  in 
managing  complex  design  problems. 

Although  ECATE  is  still  in  its  first  stages  of  evolution,  mainly  about  the  inference  rules  and  the  user 
interface,  already  shows  a  remarkably  good  achievement  of  the  first  objective  above. 

But  the  best  result  is  obtained  in  demonstrating  the  second  objective,  because  ECATE  shows  an  excellent 
flexibility  in  the  continuous  refinement  of  all  its  parts  and  a  rapid  response  to  the  changes  introduced 
bv  the  user. 
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The  latter  feature,  made  possible  by  the  Knowledge  Engineering  Environment  of  development,  is  greatly 
valuable  in  the  architectural  design,  because  it  makes  available  to  the  designer  comparison  between 
different  solutions  considered  from  different  points  of  view  and  in  overall. 

It  IS  our  belief  that  the  tools  and  techniques  of  the  Artificial  Intelligence  can  be  applied  als^t  to 
other  the  other  phases  of  the  design,  development,  testing  and  to  the  management  of  avionics,  and  non 
avionics,  system  when  complex  problem  are  implied. 

The  benefit  given  by  the  intrinsic  flexibility  of  the  powerful  knowleddge  management  techniques,  greatly 
surpasses  the  initial  cost  of  training  people  and  acquiring  tools,  and  results  in  a  better  n.ore 
effective  product. 
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(DEFUN  TOT-COST  (SYS) 

"Total  cost  coaputation  function." 

(PUT.UALUE  SYS  "TOTAL-COST 

(SUMMA  "COST  (FIND-CHILDREN  "COMPONENTS  SYS))) 
(BREAK-LIST  (FIND-CHILDREN  "COMPONENTS  SYS)  "COST  "TOTAL-COST  SYS)) 


(DEFUN  TOT-INLEUEL  (SYS) 

"Systea  integration  level  deterai nation." 

(LET  ((LIST-PROC  (LIST-CONTROL  (FIND-CHILDREN  "PROCESSORS  SYS)  NIL))) 
(PUT.UALUE  SYS  "  INTEGRATION-LEUEL 
(// 

(*  (SUMMA  "OUTPUT-INFORMATION-FLOW 

(LET  ((8IGLIST  (FIND-CHILDREN  " GENERATORS  SYS ) ) 
(PASSED-LIST  NIL)) 

(LIST-GEN-CONTROL  BI6LIST  PASSED-LIST))) 
(SUMMA  "INPUT-INFORMATION-FLOU 

(LET  ((BIGLIST  (FIND-CHILDREN  "UTILIZERS  SYS)) 
(PASSED-LIST  NIL)) 

(LIST-UTI-CONTROL  BIGLIST  PASSED-LIST)))) 
(FLOAT  (+  (SUMMA  "OUTPUT-INFORMATION-FLOU  LIST-PROC) 
(SUMMA  ■ INPUT-INFORMATION- FLOy  LIST-PROC) 
(GET.UALUE  SYS  ' TOTAL-DATA-FLOU) ) ) ) ) ) ) 
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DISCl'SSION 


E.Cambise«  IT 

Is  the  purpose  of  the  ECATH  system  to  determine  the  performance  of  an  avionic  system  composed  of  building  blocks 
with  known  performances,  or  is  it  to  determine  the  performances  of  component  building  blocks  to  achieve  the  overall 
desired  system  performance? 

Author's  Reply 

ECATE  mainly  addresses  information  processing  requirements.  Its  intended  application  is  the  former,  but  it  is  also 
possible  to  intr<xluce  prospective  performance  data  and  assess  the  cvmsequent  system  performance. 


P.R.Walwyn,  UK 

Can  the  ECATE  design  tool  be  used  to  implement  the  “decision  function  emphasis"  approach  to  system  architecture 
design  (i.e.,  the  human  interface  requirement)  outlined  in  Paper  No.  1 6.  A  Change  in  System  Design  Emphasis:  From 
Machine  to  Man? 

Author's  Reply 

Yes.  provided  a  suitable  model  of  human  interface  is  available.  ECATE  can  be  easily  incorporated  in  the  system 
desenption.  TTie  key  point  is  to  be  able  to  sort  out  the  rules  to  operate  the  human  interface. 
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1 .  LVTRODUCTQN 

This  paper  addresses  the  problems  of  providing  specifications  for  system 
components  of  the  highly  Integrated  avionic  systems  of  the  future.  The  problems  are 
discussed  in  the  context  of  the  avionic  systems  of  a  Future  Maritime  Reconnaissance 
Airc-aft  (FMRA),  The  need  and  extent  of  the  integration  of  the  avionic  systems  are 
discussed,  as  are  the  consequences  for  system  definition  and  specification.  Potential 
techniques  for  addressing  these  problems  are  reviewed.  These  are  brought  together  to 
describe  an  approach  which  could  provide  the  tools  required.  The  Implication  of  this 
approach  for  vendors  and  integrators  is  then  addressed. 


2.  THE  GROWING  NEED  FOR  AVIOKIC  SYSTEM  INTEGRATION 

It  is  not  too  much  of  a  simplification  to  say  that  in  Maritime  Reconnaissance 
aircraft  there  is  not  the  same  intimate  relationship  between  airframe  performance  and 
avionics  capability  as  there  Is  in  a  fast  .let.  Provided  the  airframe  has  the 
capability  to  carry  the  payload  required  and  to  stay  on  station  for  the  required 
duration  its  capability  as  an  overall  weapons  system  is  largely  dependent  upon  the 
capability  of  its  avionics  and  weapon  systems.  This  is  shown  by  the  fact  that  the 
Nimrod  MR  airframe  has  not  been  changed  significantly  over  the  years  but  its  avionics 
has  been  updated  on  a  number  of  occasions.  The  functionality  of  such  a  system, 
therefore,  although  not  its  Implementation,  can  be  considered  in  isolation  from  the 
airframe  in  which  it  is  Installed.  Furthermore  it  has  a  large  number  of  tactical 
sensors  and  communications  systems  to  meet  the  needs  of  different  roles  and  the 
performance  required  of  it  imposes  high  levels  of  integration  with  consequential 
problems  in  the  sped fiodt ion ,  design  and  testing  cycle. 

For  the  purposes  of  specification  and  design,  the  avionics  and  weapon  systems  are 
broken  down  into  major  systems  (Radar,  Acoustics  etc)  each  of  which  is  then  broken 
down  into  major  subsystems  and  so  on  into  their  physical  embodiment  at  the  LRU  and 
module  levels. 

The  integration  task  commences  at  LRU  level  and  progressively  builds  up  to  a 
functional  test  of  the  overall  weapon  system.  The  size  of  this  task  is  illustrated  by 
the  fact  that  a  system  such  as  Nimrod  has  of  the  order  of  ^00  avionics  LRUs  and  BOO 
avionics  LRU  interfaces,  some  simple  but  some  involving  a  large  degree  of  interactions 
between  the  subsystems.  The  architecture  of  a  typical  system  of  this  type  is  shown  in 
figure  1  and  a  typical  specification,  design  and  integration  testing  cycle  is  shown  in 
figure  2.  This  could  take  of  the  order  of  5  -  10  years. 


3. 


FUTURE  DEVELOPMENTS 


Consideration  of  the  future  threats  indicates  that  greater  performance  will  be 
required  of  future  avionics  systems.  Greater  sensitivity  in  the  sensor  heads  will 
produce  more  data  but  It  is  unlikely  to  result  in  data  better  than  that  currently 
available  and  it  may  well  be  worse.  To  maintain  or  increase  mission  success  rates 
with  these  quantities  and  qualities  of  data  will  require  more  sophisticated 
processing,  both  within  systems  and  across  systems  The  ensuing  need  for  a  higher 
level  of  integration  will,  at  its  most  extreme,  result  in  the  kind  of  system 
architecture  shown  in  figure  3  where  processing  functions  can  be  shared.  The  increase 
in  the  number  of  sensor  systems  but  reductions  in  the  size  of  elements  of  such  systems 
e.g,  by  the  use  of  VHSIC,  could  lead  to  elements  currently  specified  as  LRUs  being 
implemented  as  single  card  modules  and  sharing  an  enclosure  with  modules  from  other 
systems.  Even  if  not  fully  realised  the  flexibility  offered  by  some  of  these 
developments  will  have  similar  effects.  For  instance  the  moves  towards  general 
purpose  computing  elements  e.g.  the  Transputer,  offer  cheap,  reconf igurable  processing 
which  can  be  extended  in  a  way  which  is  functionally  transparent  to  the  software  using 
it,  except  in  performance  terms.  The  system  requirement,  and  the  software  element  of 
it,  cay  then  be  designed  without  knowledge  of  the  hardware  embodiment  and  hence 
functional  interaction  between  components  must  be  explicitly  specified. 

These  developments  will  pose  in  stark  terms  the  type  of  problems  faced  today  by 
the  specification  and  integration  of  avionic  systems.  These  are:- 

the  need  to  provide  an  unambiguous  definition  of  the  functionality  of  the 
system  and  subsystem, 

-  a  definition  of  the  dynamic  interaction  of  components  within  a  system, 

a  definition  of  the  dynamic  interactions  of  systems  across  their  interfaces. 

E0T£?jTIAL  TECRNIQU£S  TO  ADDRESS  THESE.  PROBLEMS 

Almost  all  of  the  potential  techniques  con.^idered  have  their  origins  in  software, 
where  the  abstract  nature  of  the  product  leads  to  attempts  to  define  the  requirement 
and  deliverables  as  explicitly  as  possible. 

^ .  1  PungtlonalLty 

Functionality  is  the  main  area  which  has  been  addressed.  The  techniques 
d-'/eloped  have  some  combination  of  the  following  Ideas  : 

-  diagrammatic  ’representation, 
unambiguous  notation, 

-  functional  decomposition, 

data  modelling  (for  data  base.s), 


process  model  ling. 


The  techniques  may  also  incorporate  a  set  of  rrocedures  by  which  the  techniques 
are  applied.  The  degree  of  interpretation  required  to  implement  the  functionality 
defined  is  dependent  upon  the  precision  or  degree  of  elaboration  used  by  the 
techniques  and  procedure.  Since  many  of  these  techniques  are  Intended  for  use  in 
transaction  processing  they  lack  a  means  of  temporal  representation.  They  also  range 
from  fairly  abstract  means  of  representation  to  techniques  such  as  MASCOT  which  maps 
ideas  onto  language  and  hence  leads  directly  into  tools  such  as  CONTEXT  which  converts 
MASCOT  into  CORAL.  The  type  of  technique  required  for  the  FMRA  must  provide  an 
unambiguous  representation  which  can  indicate  temporal  relationships.  It  must  support 
the  specification,  design  and  testing  cycle. 


**.2  Dynamic  Representation  of  System  ComDongnt.s 

The  idea  of  executable  specifications  and  prototyping  also  has  its  origins  in 
software.  The  production  of  a  functional  requirement  document  leaves  open  the 
question  of  whether  the  requirement,  as  It  lies  on  the  page  of  the  specification,  or 
the  initial  paper  design,  in  response  to  that  requirement,  are  viable  individually  and 
whether  the  design  is  an  adequate  response  to  the  requirement.  It  is  an  attractive 
idea  to  write  the  specification  in  software,  which  can  be  executed,  and  hence  proved 
viable,  and  to  write  a  prototype  of  the  software  design  which  can  be  proved  viable  in 
its  own  right  but  can  also  be  compared  with  the  executable  specification  for 
veri f icat ion . 

This  is  an  extremely  difficult  task  for  a  time  dependant,  highly  integrated 
system.  The  types  of  language  commonly  available  do  not  lend  themselves  to  the 
functional  modelling  of  the  requirement  and  hence  a  fair  degree  of  effort  is  required 
to  actually  construct  a  model.  Consequently  the  Idea  of  the  frequent  change  needed  to 
refine  the  requirement  is  daunting.  The  same  is  also  true  of  prototyping,  except  the 
prototype  is  invariably  more  detailed  than  the  requirement  hence  the  work  involved  in 
the  changes  is  the  greater.  The  technique  required  for  the  FMRA  must  be  capable  of 
adquately  representing  the  system  components  of  the  requirement  specification,  the 
interactions  between  these,  and  must  alsc  allow  the  definition  of  th^'  components  and 
the  interactions  to  be  changed  reasonably  easily.  The  definition  thus  established  can 
be  developed  by  more  conventional  means. 

.  3  Dynamic  Interactions  Aoros.s  Interface^ 

Interface  design  is  generally  agreed  to  be  both  difficult  and  important  but 
almost  all  the  effort  has  been  directed  at  providing  improved  or  more  detailed 
documentation.  By  its  nature  this  means  of  providing  the  Interface  specification  is 
static  and  defines  the  detail  of  an  Interface  rather  than  Indicates  the  way  in  which 
the  detail  Is  to  be  used.  It  Is  thus  open  to  more  than  one  1 ntepretat i on  because  It 
is  a  detailed  static  definition  of  a  boundary  representing  complex,  dynamic  and 
time-related  interactions  between  functions  either  side  of  the  boundary. 

The  technique  developed  to  represent  the  dynamic  representation  of  system 
components  would  produce  the  starting  point  for  such  an  interface  definition  but  It 
would  not  be  detailed  enough.  The  technique  required  for  the  FMRA  must  not  only 
represent  the  system  components  on  either  side  of  the  boundary  adequately  but  must 
also  be  able  to  represent  the  data  exchange  characteristics. 
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5.  TECHNIQUES  FOR  THE  FMRA 

5. 1  Funotionallty 

A  system  design  method  with  which  BAe  has  some  experience  is  Controlled 
Requirements  Expression  (CORE).  This  is  a  technique  which  produces  a  temporal 
representation  of  processes  with  data  passing  between  them.  Each  process  has  a 
process  description  and  each  datum  a  definition.  It  uses  the  technique  of  functional 
decomposition  and  Is  capable  of  being  continued  until  .software  is  produced.  It  is 
necessary  for  the  method  selected  to  deal  with  the  fact  that  a  weapon  system  developed 
by  a  Prime  Contractor  would  consist  of  functions  provided  by  Government,  functions 
developed  by  the  Prime  Contractor  and  functions  defined  by  the  Prime  for  a  sub¬ 
contractor. 

All  of  these  functions  can  be  defined,  to  a  greater  or  lesser  degree  of  detail  as 
appropriate,  using  CORE.  The  GFE  functions  must  be  defined  to  a  level  of  detail  which 
allows  their  effect  on  the  overall  weapon  system  and  its  major  system  be  determined. 
The  subcontracted  functions  must  be  defined  to  a  level  of  detail  which  allows  a  proper 
degree  of  control  over  the  subcontract.  The  self  to  self  function  must,  of  course,  be 
defined  to  a  production  level  of  detail.  CORE  allows  the  definition  to  be  stopped  on 
different  levels  of  detail  and  still  produce  an  adeouate  definition.  The  problem, 
both  for  current  and  future  systems,  is  establishing  the  boundaries  of  the  system. 

Figure  shows  how  a  current  LRU  based  system  would  be  broken  down  in  this  way. 
Figure  shows  an  equivalent  diagram  of  a  future  system  indicating  that  the  method 
oan  be  used  to  produce  a  requirement  definition  for  a  future  system.  This  definition 
is  however  a  static  one. 

5.2  Dynamic  Representation  of  System  Components 

The  definition  of  a  major  system,  such  as  Radar,  in  CORE  would  produce  functional 
descriptions  of  the  major  blocks  (see  figure  5).  Figure  6  shows  an  expansion  of  the 
tracking  block  where  the  "track  control"  process  description  Is  given.  This  type  of 
description  in  which  the  process  is  described  In  the  form  rules  relating  input  data, 
output  data  and  Intermediate  results,  is  evocative  of  a  Knowledge  Based  Systems  using 
production  rules.  The  essence  of  such  systems  Is  the  ease  of  changing  the  knowledge 
compared  to  a  system  written  in  a  conventional  language  where  the  knowledge  is 
implicit  in  the  structure  of  the  software,  hoing  an  architecture  known  as  a  Multiple 
Blackboard  architecture  a  model  of  the  system  could  be  built  up  from  the  processes 
defined  by  CORE.  Each  major  system,  e.g.  RADAR,  could  have  its  own  blackboard  upon 
which  the  system  functions,  e.g.  signal  processing  or  tracking,  read  data  intended  for 
Knowledge  Sources  (KS)  e.g.  track  control,  and  write  data  from  KS  e.g.  transmit  track. 

These  blackboards  are  themselves  the  KSs  for  a  system  blackboard  on  which  the 
major  systems  read  and  write  data  (Figure  7).  This  type  of  approach  meets  the 
characteristics  stated.  These  are: 


a ) 

it 

is 

capable 

of 

adequately 

representing 

the 

components  in  CORE 

b) 

it 

is 

capable 

of 

adequately 

representing 

the 

interaction  in  CORE 

then 

in  KBS 
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c)  the  definition  of  component  and  Interaction  can  be  changed 
reasonably  easily  -  this  Is  an  attribute  of  a  KBS 

Since  the  system  is  defined  in  terms  of  functions,  boundaries  can  be  defined 
which  produce  (arbitrary)  groupings  and  the  Interfaces  between  them.  Such  a  grouping 
could  be  GFE  or  subcontracted  functions  and  changes  to  such  functions  could  be 
reflected  throughout  the  model.  The  model  is  thus  capable  of  testing  the  effect  of 
changes  in  the  subsystem  functions  and  the  overall  system  regardless  of  the  physical 
boundaries  of  the  subsystem  (Figure  6). 

If  a  great  deal  of  detail  is  required  in  the  model  it  will  be  necessary  to 
develop  a  model  of  the  major  systems,  the  multiple  blackboard  architecture  lends 
itself  to  this  line  of  development. 

5.3  Dynamic  Interactions  Across  Interface 

From  the  foregoing  discussion  It  Is  apparent  that  the  same  general  approach  would 
also  be  appropriate  for  interactions  across  interfaces.  An  Interface  definition  is  an 
evolving  definition.  It  starts  with  sparse  detail  and  gradually  is  developed  until  it 
can  become  so  detailed  that  it  is  not  fanciful  to  describe  it  as  encrusted  (and 
virtually  impossible  to  verify  or  validate).  It  also  combines  functional  data  on  what 
systems  do  with  data  on  protocol  and  procedure;  the  CORE  definition  will  provide  the 
former,  the  traditional  ways  of  defining  protocol  and  procedures  will  produce  the 
latter.  In  considering  protocol  and  procedures  it  is  only  necessary  to  recall  that 
these  are  other  names  for  rules  to  see  that  the  CORE/KBS  approach  is  appropriate  both 
for  existing  LRU-baaed  systems  and  for  future  systems  (Figures  9  and  10). 

It  should  be  noted  that  interface  definition  Is  required  between  all  functional 
groups  whether  GFE,  subcontracted  or  in-house  developed. 


These  three  types  of  task  can  come  together  into  a  coherent  approach  (Figure  11). 
The  overall  system  can  be  defined  in  CORE  to  the  point  at  which  groupings  are 
established.  These  can  be  modelled  using  the  CORE/KBS  approach  as  can  the  interfaces 
between  these  groupings.  After  this  point  GFE  functions  are  only  modelled  In  the 
detail  required  to  support  the  other  functions.  This  means  in  full  detail  for  the 
interface  models.  The  CORE  definition  of  the  other  functions  and  subsequently  the 
CORE/KBS  models,  are  developed  to  the  level  of  detail  required  to  allow  the  definition 
of  subcontracted  functions  and  their  interfaces  to  be  delivered  to  the  subcontractor. 
After  this  point,  subcontracted  functions  are  modelled  to  the  level  of  detail  required 
to  support  the  other  functions  and  allow  control  of  the  subcontracts  to  be  maintained. 
This  involves  full  detail  of  the  interface  models. 
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7.  IMPLICATIONS 

The  preceding  discussion  deals  only  with  issues  arising  from  the  need  to  provide 
an  effective  means  of  specifying  and  designing  a  highly  integrated  system.  There  Is 
evidence  that  subcontractors  are  reluctant  to  accept  as  specifications  anything  other 
than  conventional  documentation.  The  existence  of  in-house  methods;  the  investment  in 
trained  personnel;  the  flexibility  afforded  by  the  In-house  decision  as  to  how  a 
requirement  specification  will  be  used  is  the  •'asis  of  a  design;  these  are  all  factors 
which  will  hinder  the  adoption  by  a  Prime  Contractor  of  a  specification  and  design 
approach  which  is  based  on  handing  over  software  models  as  part  of  a  requirement 
specification  to  be  met.  More  particularly  this  approach  brings  In  its  wake  the 
question  of  standardisation  on  computer,  operating  system  and  software  tools.  The 
approach  is,  in  any  case,  fairly  ambitious  in  its  demands  upon  the  KBS  architecture 
(still  in  development)  and  the  software  tools  needed  to  produce  such  models  (currently 
KBS  shells  are  special  to  type).  Whether  the  approach  achieves  a  realisation  Is 
largely  dependent  upon  whether  the  needs  of  future  platforms  demand  such  highly 
integrated  systems . 
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SUMMARY 

The  design  requirements  for  future  airborne  weapon  systems  show  an  increasing  drive 
towards  ijiipioviuy  their  overall  performance  and  flexibility  whilst  at  the  same  time 
reducing  the  total  weight  and  the  resulting  cost-  These  requirements  generate  the 
need  for  much  closer  integration  of  the  subsystems  which  make  up  the  total  weapon  system. 
This  approach  to  total  systems  integration,  forces  the  weapon  system  designer  to  look 
for  improved  design  techniques  which  are  capable  of  coping  with  the  complexity  and 
high  interdependence  of  the  various  functions  involved. 

This  paper  describes  a  structured  approach  to  the  design  of  highly  integrated  weapon 
systems  of  the  future.  The  approach  was  used  in  the  successful  design  and  development 
of  the  avionics  system  for  the  UK  Experimental  Aircraft  Programme  (EAP)  demonstrator 
aircraft.  Brief  descriptions  are  given  of  the  EAP  systems,  the  main  system  design 
tools  used,  the  activities  carried  out  during  the  systems  design  process  and  the 
management  and  control  procedures  adopted.  The  paper  concludes  with  a  series  of  obser¬ 
vations  highlighting  some  of  the  findings  of  the  project  and  providing  pointers  to 
the  design  of  future  weapon  systems. 

1 .  INTRODUCTION 

The  prime  purpose  of  this  paper  is  to  describe  a  structured  approach  to  the  design 
of  a  weapon  system  which  British  Aerospace  (BAe)  were  able  to  develop  and  prove  during 
the  design  of  the  avionics  system  for  the  Experimental  Aircraft  Programme  (EAP)  demon¬ 
strator  air''*‘'2ft,  ui-.r-fL.  first  flew  in  the  United  Kingdom  in  August,  1986. 

i>4.ief  descriptions  are  given  of  the  EAP  systems,  the  main  system  design  tools  used, 
the  activities  carried  out  during  the  systems  design  process  and  the  management  and 
control  procedures  adopted.  In  addition  a  series  of  observations  highlighting  some 
of  the  findings  of  the  project  and  providing  pointers  to  the  design  of  future  weapon 
systems  are  given. 

What  is  a  structured  approach?  -  A  structured  approach  can  be  defined  as  a  methodical 
or  step  by  step  process  involving  the  pr-^gresslve  development  of  concepts  from  the 
start  of  the  design  process  to  its  completion.  This  contrasts  greatly  with  the  ad 
hoc  methods  which  have  been  used  in  the  past  and  have  been  found  deficient  in  surh 
areas  as  the  lack  of  definition  or  the  late  discovery  of  design  or  specifiration 
problems  leading  to  costly  modifications.  In  no  way  does  the  structured  approach  remove 
the  need  for  engineering  judgement  or  skill,  it  does  however  highlight  the  need  to 
make  engineering  decisions  at  the  appropriate  time  to  allow  the  design  process  to 
proceed . 

Why  a  structured  approach?  -  As  technology  continues  to  advance  so  the  requirements 
demanded  of  the  next  generation  of  weapon  systems  also  increase-  This  increase  is 
two-fold;  improvement  in  the  performance  of  existing  requirements  such  as  detection 
ranges  or  navigation  accuracy  and  improvement  in  operational  flexibility  by  the 
combination  of  requirements  such  as  air  combat  and  electronic  counter  measures  into 
one  vehicle.  In  this  age  of  the  ever  increasing  demand  for  the  use  of  new  technology, 
it  is  essential  that  its  use  is  kept  within  the  bounds  of  what  can  be  afforded.  In 
the  case  of  an  airborne  weapon  system,  weight  is  considered  to  be  a  very  important 
cost  driver.  The  heavier  the  avionic  equipment,  the  greater  the  demand  it  makes  on 
the  aircraft,  i.e.  airframe,  engines,  fuel,  etc.,  which  leads  to  a  heavier,  costlier 
aircraft.  There  is  therefore  a  very  strong  requirement  to  minimise  the  weight  of  any 
airborne  weapon  system. 

In  the  past  it  was  considered  acceptable  for  individual  system  elements  to  stand 
alone.  This  often  led  to  some  duplication  in  the  provision  of  sensors,  processors 
or  displays.  The  demands  for  minimising  the  total  system  weight  removes  any  possible 
duplication  of  the  system  elements  and  leads  to  a  highly  integrated  weapon  system  where 
some  equipments  may  undertake  several  functions.  It  is  this  complexity  and  interdepend¬ 
ence  of  the  various  functions  involved  which  forces  the  weapon  system  designer  to  look 
for  improved  design  techniques. 

It  was  therefore  considered  that  the  following  features  should  be  embodied  in  the 
processes  to  be  used  for  the  design  of  the  EAP  avionics  system:- 

a  step  by  step  approach  which  progressively  develops  the  design  rationale  and 
pro'Mdes  a  capability  for  planning  the  execution  of  the  design  and  for 
monitoring  its  progress. 
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a  precise,  consistent  and  unaiiibigious  way  of  expressing  system  requirements 
at  all  levels. 

a  means  of  applying  checks  at  different  stages  of  the  design  life  cycle  to 
detect  errors  of  specification  or  design  in  order  to  assure  the  design  quality. 

an  ability  to  demonstrate  that  the  requirements  have  been  met  in  order  to 
provide  traceability  of  the  requiiemeuts . 

The  above  features  constitute  the  structured  approach  which  was  adopted  by  BAe  and 
which  are  discussed  in  more  detail  in  this  paper. 

2.  EAP 

While  EAP  has  been  created  relatively  quickly,  its  origins  go  back  at  least  ten 
years.  During  this  period,  engineers  at  BAe  worked  on  various  studies  for  a  new  fighter 
aircraft  incorporating  twin  engines,  delta  v/ings,  canards  and  bocn  single  and  twin 
fins.  Some  of  these  studies  were  undertaken  in  collaboration  with  other  Companies. 

In  1979  a  proposal  for  a  European  Combat  Fighter  (ECF)  was  put  to  the  British  and  German 
governments  jointly  by  BAe  and  Messerschmitt-Bolkow-Blohm  (MBB),  while  in  1980  a  slightly 
modified  design  for  a  European  Combat  Aircraft  (ECA)  was  prepared  by  BAe,  Dassault- 
Breguet  and  MBB  and  put  to  their  respective  governments.  Unfortunately  the  governments 
were  unable  to  reach  agreement  on  a  common  set  of  requirements. 

During  1981  BAe  continued  its  studies  and  defined  the  PllO  project  which  involved 
the  UK  Avionics  Industry  in  agreeing  a  weapon  system  architecture  and  producing  equipment 
specifications.  At  the  same  time  MBB  were  working  up  their  TKF90  project  which  was 
very  similar  to  the  PllO  project-  Therefore  in  April  1982,  BAe  and  MBB  together  with 
Aeritalia  who  had  previously  co-operated  to  design  and  build  the  Tornado  aircraft, 
agreed  to  investigate  the  possibilities  of  producing  a  joint  specification  to  meet 
their  individual  national  requirements.  The  resulting  Agile  Combat  Aircraft  (ACA) 
was  unveiled  in  mock  up  fom.  at  the  1982  Farnborough  Air  Show  am  the  CK  government 

—  e'  •ould  provide  suppc'-t  for  a  dcmonstrotoi  air.-..aft  i)Ar  which  ^ould 

ilown  at  the  1986  Farnborough  Air  Snow. 

It  was  anticipated  that  two  demonstrator  aircraft  based  on  the  ACA  design  would 
be  built,  one  in  Great  Britain  and  one  in  Germany.  During  1983  a  limited  systems  fit 
was  agreed  for  the  aircraft  and  due  to  the  tight  timescale  of  the  project,  equipment 
specifications  were  produced,  put  out  to  tender  and  Suppliers  selected,  very  much 
in  advance  of  the  carrying  out  of  a  detailed  system  design.  Unfortunately  as  a  result 
of  the  German  and  Italian  Governmerts  decisions  to  withdraw  at  the  end  of  1983,  work 
on  the  German  aircraft  did  not  proceed.  However  the  chosen  equipment  suppliers  from 
the  three  countries  accepted  BAe's  invitation  to  con’-inue  with  the  design,  build  and 
supply  of  the  numerous  equipments  required,  without  charge,  for  the  single  demonstrator 
ai rcraf t . 

In  obtaining  the  agreement  of  the  UK  government  to  provide  support  for  the  demonstrator 
aircraft,  it  was  necessary  to  agree  the  objectives  which  would  be  demonstrated.  The 
areas  chosen  covered  the  fields  of  aerodynamics,  structures  and  materials,  and  systems 
and  involved  the  development  and  demonstration  of  procedures  necessary  for  the  design, 
manufacture  and  test  in  these  areas  which  were  considered  relevant  to  a  future  fighter 
aircraft . 

This  paper  concentrates  on  the  work  carried  out  in  th<?  design  and  development  of 
the  avionics  system  involving  the  use  of  the  MIL  STD  1553B  data  bus  and  the  mudern 
electronic  cockpit  which  were  the  responsibility  of  the  authors. 

3.  EAP  SYSTEMS 

The  EAP  has  three  major  electronic  systems:  Flight  Control  System,  Utilities  Services 
Management  System  and  Avionics  System,  the  latter  comprising  communications,  navigation 
and  displays  and  controls  subsystems.  A  simplified  system  architecture  is  shown  in 
Fig.  1. 

3  . 1  Flight  Control  System 

The  EAP  has  a  full  authority,  digital  fly  by  wire  system  to  provide  artificial  stability 
and  the  necessarily  complex  control  functions.  This  system  is  based  on  the  Jaguar 
Active  Control  Technology  aircraft  which  was  the  first  aircraft  to  use  fly  by  wire 
for  flight  control  without  mechanical  back  up.  The  system  controls  up  to  13  surfaces 
simultaneously.  The  four  identical  flight  control  computers  host  the  flight  software 
which  enables  the  pilot  to  fly  the  unstable  aircraft  and  provides  carefree  manoeuvrability 
and  increased  agility.  The  computers  also  house  software  for  failure  management,  reversion 
logic  and  built  in  test.  The  computers  receive  inputs  from  the  four  aircraft  motion 
sensors,  four  attitude  detectors,  two  air  data  computers  and  pilot  inceptors  and  provide 
the  outputs  to  the  control  sn^’faces.  In  addition  they  provide  air  data  information 
to  the  utilities  and  avionics  systems  via  the  two  MIL  STD  1553B  data  buses  and  air 
date,  attitude  and  heading  to  the  reversionary  instruments. 
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3 . 2  Utility  Services  Management  System 

While  not  originally  claimed  as  a  technological  demonstration  feature,  the  EAP 
adopted  an  integrated  computing  system  for  the  control  and  management  of  the  aircraft 
utility  systems.  The  system  comprises  four  system  management  processors  connected 
to  a  dual  redundant  MIL  STD  1553B  data  bus.  The  bus  control  function  is  embedded  in 
two  of  the  processors.  The  main  utility  systems  which  are  controlled  by  the  processors 
are  as  follows:- 

fuel  management  and  fuel  gauging 

hydraulic  system  control  and  indication 

undcrc?'»-ri  aae  indication  and  monitoring,  wheel  brakes 

environmental  control  system  including  cabin  temperature  control 

engine  control  and  indication 

secondary  power  system 

LOX  contents,  electrical  generation  and  battery  monitoring,  probe  heating 

The  main  benefits  of  this  type  of  system  for  a  high  performance  aircraft  are  a  signif¬ 
icant  reduction  in  installed  weight  and  operating  costs,  and  a  large  improvement  in 
availability.  It  also  provides  a  simple  interface  to  the  avionics  system  in  particular 
for  the  cockpit  electronic  displays  and  controls,  this  being  one  of  the  original  drivers 
in  evolving  the  system. 

3  .  3  Avionics  System 

It  was  accepted  that  for  the  EAP,  the  avionics  system  would  be  a  sub-set  of  the  weapon 
system  proposed  for  the  ACA.  This  was  called  the  'Core  System'  and  provides  the 
essential  features  to  fly  a  high  performance  aircraft  namely  navigation,  communications 
and  display  and  control  functions.  Transmission  of  data  between  the  subsystems  is 
via  a  dual  redundant  MIL  STD  1553B  data  bus.  This  greatly  reduces  the  amount  of  wiring 
required  in  the  aircraft  and  simplifies  the  development  and  on-aircraft  testing. 

The  navigation  subsystem  comprises  an  inertial  platform  wirh  its  own  se  1  f-oonta  incKl 
navigation  processor  and  a  TACAN  and  radar  altimeter  which  share  the  same  remote  terminal. 

The  communications  subsystem  comprises  a  standard  V/UHF  radio  and  an  emergency  UHF 
radio.  The  control  of  this  equipment  is  through  an  integrated  control  and  management 
unit  which  also  provides  a  voice  warning  facility.  The  latter  supplements  the  normal 
aircraft  warning  system. 

The  displays  and  controls  subsystem  demonstr<ates  several  new  technologies.  Two 
identical  v’nvefcrm  generators  form  the  heart  of  the  subsystem  and  are  each  capable 
of  driving  the  three  multi  function  colour  displays  and  the  wide  angle  holographic 
head  up  display.  They  also  provide  the  bus  control  and  executive  control  functions 
for  the  avionics  system.  Mission  data  such  as  waypoints,  TACAN  beacons,  communication 
channels  etc.,  arc  inserted  by  the  pilot  via  the  manual  data  entry  facility  mounted 
on  the  left  hand  glareshield.  This  information  together  with  raw  control  data  from 
the  controls  mounted  on  the  consoles,  throttles,  control  stick  and  displays  is  processed 
in  two  identical  cockpit  interface  units  prior  to  being  transmitted  on  the  avionics 
data  bus.  A  cockpit  lighting  controller  undertakes  the  task  of  monitoring  the  light 
sensors  distributed  around  the  cockpit  and  continuously  regulates  the  power  supplied 
to  all  the  displays  and  controls  to  provide  optimum  illumination  and  display  contrast 
at  all  times. 

4  .  DESIGN  TOOLS 


In  parallel  with  the  work  being  carried  out  on  fighter  aircraft  studies  during  the 
70’ s,  BAe  put  considerable  effort  into  examining  ways  of  improving  the  techniques  used 
for  designing  systems  and  also  into  the  newer  system  technologies.  Two  specific  areas 
which  showed  promise  and  were  pursued  with  the  support  of  the  UK  government,  were; 

means  of  improving  the  production  of  airborne  software  in  terms  of  productivity 
and  quality 

investigations  into  the  implementation  of  a  MIL  STD  1553B  databus  together 
with  an  all  'electronic'  cockpit  including  the  raulti-moding  of  displays  and 
controls . 

The  former  led  to  the  development  of  an  approach  called  Semi -Automated  Functional 
Requirement  Analysis  (SAFRA)  while  the  latter  led  to  the  production  of  the  Active  Cockpit. 
Both  of  these  tools  were  used  to  support  the  design  of  the  avionics  system  for  EAP 
and  are  described  in  the  following  paragraphs. 
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4 . 1  Semi -Automated  Functional  Requirerents  Analysis  (SAFRA ) 

In  examining  ways  of  improving  the  productivity  and  quality  of  airborne  software 
it  was  shown  that  the  biggest  improvements  would  be  obtained  by  the  ability  to  find 
and  eliminate  errors  at  as  early  a  stage  as  possible  in  the  software  life  cycle.  This 
led  to  the  development  of  the  approach  called  SAPRA  which  in  particular  addressed  the 
lack  of  method,  lack  of  visibility,  lack  of  consistency  and  resolution  of  ambiguities 
in  producing  software  requirements.  Just  as  this  method  was  applied  tc  software 
requirements  it  was  shown  that  it  could  be  applied  to  the  establishing  of  system  require¬ 
ments  and  was  therefore  also  adopted  for  this  latter  purpose. 

The  SAPRA  approach  encompasses  a  number  of  methods  and  tools  which  support  the  various 
stages  of  the  system/software  life-cycle.  At  the  heart  of  SAFRA  is  a  method  called 
controlled  Requirements  Expression  (CORE)  which  is  used  to  produce  system  and  software 
requirements  that  are  unambiguous,  consistent  and  complete.  The  method  is  based  on 
the  progressive  decomposition  of  high  level  requirements  in  a  logical  and  consistent 
manner  until  a  level  is  reached  where  the  requirements  are  expressed  in  sufficiently 
precise  detail  to  allow  hardware  and  software  design  to  commence. 

Each  level  of  decomposition  consists  of  a  number  of  logical  steps,  eleven  in  all, 
which  when  applied  to  a  higher  level  requirement  produces  the  lower  level  components 
of  the  require"'^nt .  These  steps  cari  ly  suiwnarised  as  information  gathering, 

establishment  of  relationships  and  the  verification  of  relationships.  The  information 
derived  at  each  level  of  decomposition  is  presented  in  diagrammatic  form  known  as  CORF 
diagrams.  These  diagrams  use  a  precise  unambiguous  notation  which  can  be  checked  for 
consistency  and  completeness  across  the  whole  of  the  systems  requirement. 

To  assist  in  the  production  of  CORE  diagrams,  a  work  station  was  developed  which 
enables  diagrams  to  be  entered  at  a  high-resolution  graphics  terminal  and  edited  as 
required.  it  also  provides  a  multi-user  database  in  which  diagrams  are  stored  and 
a  hard  copy  facility  using  a  printer-plotter.  Some  automatic  on-line  checking  of 
the  diagrams  for  consistency  is  undertaken  as  they  are  being  entered. 

By  producing  th*^  requirements  in  an  unambiguous  form  in  a  computer  database  it  is 
possible  to  check  the  data  for  consistency  and  completeness.  This  was  done  using 
PSL/FSA  (Problem  Statement  Language/Problem  Statement  Analyser),  which  is  a  product 
of  the  ISOOS  project  of  the  University  of  Michigan,  although  other  similar  products 
such  as  EPOS  are  now  available.  The  CORE  notation  is  automatically  described  in  PSL 
in  a  consistent  manner  and  stored  in  a  new  database.  PSA  is  then  used  to  provide  checking 
and  analysis  of  the  database  in  numerous  ways.  When  all  the  ci.ecks  have  been  satisfactorily 
completed  at  each  level  of  decomposition,  the  CORE  database  is  made  read-only  to  allow 
the  next  stage  of  the  design  to  proceed. 

4 . 2  Active  Cockpit 

As  the  result  of  its  continuing  development  studies,  BAe  gained  considerable  experience 
in  the  operation  of  active  cockpit  facilities  and  demonstrated  their  great  importance 
in  providing  information  on  the  man-machine  interface  to  the  system  design  process. 

In  effect  this  facility  provides  a  means  by  which  rapid  prototyping  of  ideas  can  be 
tested  and  developed  with  full  operator  inte»-a«'* •» on . 

The  Active  Cockpit  consists  of  a  wooden  shell  representing  tho  actual  cockpit. 

The  displays  and  controls  are  positioned  to  the  best  information  available,  use  bein-^ 
made  of  commercial  items  wherever  possible.  Initially  static  displays  are  a.sSGssed 
for  the  development  of  the  moding  and  formats.  These  displays  are  then  driven  dynamically 
in  a  representative  manner  together  with  other  simulated  functions  such  as  engines, 
hydraulics , fuel  etc.,  to  fully  exercise  the  cockpit  displays  and  controls.  To  allow 
assessment  under  realistic  flight  conditions  an  outside  world  simulation  system  is 
provided.  in  addition  a  comprehensive  fault  injection  system  is  used  to  allow  assessment 
of  the  pilot/cockpit  interface  under  single  or  multiple  system  failure  conditions. 

5.  SYSTEM  DESIGN  ACTIVITIES 

The  life-cycle  stages  in  the  design  and  development  of  a  typical  system  are  illustrated 
in  figure  2.  These  can  be  grouped  under  three  main  headings  namely  system  design, 
system  implementation  and  system  test.  As  defined  system  design  covers  the  stages 
of  activity  from  the  establishment  of  the  initial  high  level  system  requirement  through 
several  levels  of  decomposition  which  produce  the  detailed  requirements  including  hardware/ 
software  partitioning  to  the  production  of  hardware  and  software  spoci f icat ions .  System 
implementation  covers  the  stages  from  the  availability  of  specifications  through  tc  their 
realisation  in  either  hardware  or  software.  System  tost  covers  the  stages  of  testing 
ataiLmg  with  individual  equipments  and  software  modu’eu  t^nd  building  up  individual 
elements  to  subsystems  and  finally  integrating  these  to  form  the  total  system. 

The  following  paragraphs  describe  in  more  detail  the  various  activities  undertaken 
during  the  system  design  process.  These  activities  are  considered  under  four  major 
headings:  design  planning,  data  gathering,  functional  analysis  and  partitioning. 
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5 . 1  Design  Planning 

Design  planning  focused  on  the  production  of  a  design  route  map  which  is  illustrated 

in  Figure  3.  This  route  map  showed  how  each  of  the  design  teams  intended  to  produce 

formal  design  documentation.  Each  system  route  map  was  also  required  to  show  the 
dependence  of  one  design  task  on  another  so  that  a  sensible  programme  could  be  derived. 
Technical  details  relating  to  the  use  of  CORE  were  also  included  e.g.  the  number  of 
levels  of  design  decomposition  were  considered  and  documented/  and  naming  conventions 
for  data  items  were  included.  To  ensure  proper  interfacing  and  integration  of  the 
main  aircraft  systems,  the  points  at  which  formal  design  reviews  would  be  held,  were 
also  defined.  This  ensured  that  the  system  design  was  properly  integrated  thereby 
avoiding  the  need  for  major  and  time  consuming  design  revisions  late  in  the  programme. 

The  route  map  also  defined  a  list  of  formal  documents  which  were  to  be  produced 
and  delivered  to  other  organisations.  For  example  the  systems  design  team  were  tasked 
with  providing  the  software  team  with  software  requirements  and  software  specifications; 
the  scope  and  depth  of  each  of  these  documents  were  also  defined. 

5 . 2  Data  Gathering 

A  data  gathering  activity  occurs  in  any  project  either  as  a  conscious  or  an  unconscious 
action.  Probably  the  most  commonly  accepted  need  at  the  start  of  any  project  is  to 
obtain  a  basic  design  requirement  for  the  aircraft.  This  is  usually  provided  hy  a 
formal  requirement  from  the  customer  such  as  an  air  staff  target  or  requirement.  In 
the  case  of  EAP  no  such  requirement  existed  and  it  was  therefore  necessary  for  the 
aircraft  companies  to  produce  a  similar  document.  During  the  definition  of  the  ACA 
project,  attempts  had  been  made  to  establish  an  air  vehicle  specification.  It  was 
therefore  possible  to  modify  this  specification  to  reflect  the  intended  standard  of 
the  EAP,  This  was  then  used  to  establish  the  areas  of  high  technology  to  be  demonstr *  ‘ '‘'® 
which  formed  the  basis  of  the  agreement  with  the  UK  gov^^rnm*^”*-  for  providing  s*.(me 
of  the  funding  for  the  project.  Thus  some  constraints  and  guidelines  were  formally 
agreed  at  an  early  stage  of  the  project. 

To  complement  the  basic  'customer*  requirement,  the  design  teams  produced  a  set 
of  pxtsliminary  systems  descriptions.  In  effect  these  descriptions  were  based  on  design 
which  embodied  experience  resulting  from  rig  demonstrator  programmes,  advanced  aircrafc 
studies,  and  a  knowledge  of  the  state-of-the  -art  in  equipment  and  systems.  They  were 
not  validated  design  documents  and  subsequently  were  not  maintained  as  formal  design 
statements.  These  descriptions  were  formally  reviewed  by  the  project  management  early 
in  1984  .  It  is  of  significance  that  subsequent  to  the  issuing  of  the  systems  descriptions 
no  further  major  changes  in  requirements  were  permitted  until  this  initial  design  had 
been  implemented.  This  meant  that  a  relatively  stable  set  of  design  objectives  were 
available. 

A  further  stage  in  the  data  collection  was  the  production  of  a  set  of  principles 
and  philosohpies  which  would  guide  the  subsequent  detailed  design.  A  typical  example 
was  to  derive  the  concepts  for  displays  and  controls  moding  for  ergonomic  single  crew 
operation.  Also  important  at  this  stage  was  the  prototyping  of  design  ideas,  and  in 
particular  the  use  of  the  active  cockpit  rig  discussed  in  Section  4.2.  This  facility 
allowed  pilots  and  designers  to  assess  design  concepts.  Because  of  the  lead  times 
needed  to  produce  such  a  facility  the  active  cockpit  did  not  provide  validated  design 
data  during  the  data  collection  phase,  however  all  of  the  information  to  be  used  on 
the  rig  was  also  made  available  to  the  system  designers.  In  this  way  rig  based  revisions 
were  fed  into  formal  design  documents  at  a  later  stage,  but  in  advance  of  the  design 
freeze  prior  to  subsystem  testing. 

Finally  an  area  of  data  collection  which  is  either  overlooked  or  is  paradoxically 
taken  to  be  a  comprehensive  statement  of  a  design  is  that  of  pre-defined  functions. 

On  EAP  several  of  the  required  functions  could  be  obtained  by  the  use  of  existing  or 
slightly  modified  equipments,  typically,  TACAH  IFF  and  inertial  navigators.  The  non¬ 
standard  aspects  of  these  of  these  equipments  was  not  related  to  the  functions  they 
provided  but  to  the  way  in  which  the  equipments  would  be  interfaced.  Thus  by  defining 
in  CORE  the  functions  and  data  requirements  for  these  equipments,  constraints  were 
placed  on  the  design.  it  also  enabled  significant  pieces  of  the  system  'puzzle'  to 
be  put  in  place  quickly  and  used  to  drive  out  other  less  well  defined  system  requirements. 
It  should  be  noted  that  this  is  a  technique  which  is  generally  applicable.  For  example 
the  weapons  fitted  to  a  new  aircraft  are  rarely  completely  new  and  hence  the  accuracy, 
functions  and  data  requirements  of  many  weapons  will  be  known  at  the  initial  design 
stage  and  should  therefore  be  usN^d  to  drive  the  design  of  the  interfacing  equipment. 

5 . 3  Furctional  Analysis 

Functional  requirements  analysis  was  the  first  formal  design  stage  of  EAP  and  used 
the  CORE  systems  design  tool.  Because  CORE  is  essentially  a  method  for  documentating, 
analysing  and  validating  a  design,  all  the  preceeding  informally  derived  data  was  first 
entered  into  the  system  CORE  design  database.  As  an  example  the  initial  step  in  CORE 
is  to  propose  the  main  system  functions  and  then  to  postulate  their  data  requirements. 

This  is  formally  referred  to  as  tabular  entries,  and  much  of  this  data  was  available 
from  the  previous  stage  of  data  gathering.  However,  because  of  the  diagrammatic  nature 
of  CORE  and  the  fact  that  the  design  data  is  electronically  stored,  it  could  be 
validated  for  functional  completeness  and  consistency  using  the  PSL/PSA  tool  e.g.  for 
each  data  source  there  must  be  a  user. 
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Initial  system  moding  was  also  proposed  at  this  stage.  Each  function  was  described 
in  terms  of  its  various  modes  or  states  so  that  the  control  data  needed  to  ._nter/exit 
a  particular  mode,  and  the  specific  data  produced  in  that  state  were  defined. 

Space  does  not  allow  all  of  the  separate  and  formal  design  steps  associated  with 
CORE  to  be  discussed  here,  however  the  benefits  arising  from  this  formalism  were  numerous. 
Direct  benefits  included  automatic  checking  of  gross  system  inconsistencies,  automatic 
production  of  interface  control  documents  for  the  major  systems,  and  a  clear  definition 
of  the  bus  control  transaction  table  requirements.  Of  less  importance  at  the  functional 
design  stage  but  of  considerable  benefit  later  during  systems  testing  was  the  ability 
of  the  various  disciplines  (test,  system  design,  and  software),  to  quickly  trace  a 
fault,  isolate  the  cause,  and  correct  the  problem  without  inducing  additional  problems 
elsewhere  in  the  system.  The  formalism  and  visibility  provided  by  the  CORE  design 
method  also  dramatically  reduced  the  number  of  errors  which  were  detected  during  the 
final  stages  of  system  integration  testing. 

To  provide  sufficient  detail,  the  design  of  the  avionics  system  was  completed  in 
three  separate  stages. 

The  first  stage  was  the  production  of  a  functional  statement  known  as  the  system 
functional  requirement  document  which  described  the  system  functional  requirements 
without  reference  to  mechanisation  or  location  and  was  derived  from  the  aircraft 
specif ication, systems  descriptions  and  the  principal  and  philosophy  documents 
which  had  been  produced .  It  also  defined  the  information  flows  to  and  from 
the  avionics  system. 

-  The  second  stage  involved  the  docomposition  of  the  system  functional  requirements 
to  establish  subsystem  functional  requirements.  This  provided  more  detailed 
definition  of  data  attributes,  transfer  rates  and  interface  details  such  as 
word  formats.  It  also  included  the  overall  sequence  of  operation  of  the  various 
functions  and  their  iteration  rate.  This  resulted  in  deriving  the  data  interfaces 
between  subsystems/equipments . 

The  third  stage  involved  further  decomposition  of  the  subsystem  functional 
requirements  to  produce  the  detailed  hardware  and  software  requirements. 

The  software  requirements  were  in  fact  produced  in  two  phases.  As  soon  as 
the  data  interface  requirements,  sequence  of  operations  and  iteration  rates 
were  available  from  stage  two,  it  was  possible  to  define  the  software  schedules 
and  the  overall  structure  of  the  code  so  that  the  software  basic  design  could 
proceed.  The  next  phase  was  to  add  the  details  of  the  process  algorithms. 

This  enabled  the  software  task  to  be  completed  by  coding  the  algorithms  which 
were  in  principle  inserted  into  the  basic  design  as  process  modules. 

5 . 4  Partitioning 

It  is  clear  that  at  some  stage  there  must  be  a  transition  from  the  purely  functional 
design  requirement  to  an  implementable  system  specification.  For  the  most  part  this 
transition  was  done  during  the  second  stage  of  the  functional  analysis.  The  main  functions 
were  partitioned  into  equipments,  and  in  the  case  of  multiprocessor  units,  they  were 
allocated  to  specific  processors.  However,  this  procedure  was  not  a  simple  single 
step  action.  The  main  systems  were  partitioned  at  the  first  stage  i.e.  functions  which 
were  to  be  carried  out  within  the  flight  control,  utilities  and  avionics  systems  were 
defined.  Subsequently  each  of  the  functions  allocated  to  these  systems  were  partitioned 
to  appropriate  subsystems.  For  example,  avionics  partitioned  functions  to  the  navigation, 
communication,  displays  and  controls  subsystems. 

This  partitioning  process  took  account  of  such  system  technical  requirements  as 
minimising  data  bus  load  requirements  and  data  latency  and  providing  adequate  failure 
mode  handling.  In  addition  project  considerations  such  as  minimum  weight  and  the  use 
of  pre-defined  equipments  were  also  taken  Into  account. 

It  was  found  quite  acceptable  in  certain  instances  to  split  up  functions  amongst 
the  various  equipments  or  processors  or  to  combine  several  functions  in  a  single  equipment 
or  processor.  The  main  requirement  was  that  the  design  was  clearly  documented. 

Two  examples  are  given  to  illustrate  the  above  mentioned  forms  of  partitioning. 

The  EAP  avionics  system  included  an  intelligent  voice  warning  system  which 
involved  two  fundamentally  different  disciplines,  the  voice  audio  generation 
and  management  and  the  logic  associated  with  recognising  a  failure  and  associating 
this  with  a  specific  warning  requirement.  The  waveform  venerators  were  in  effect 
natural  hosts  for  a  good  deal  of  the  system  data  and  hence  were  already  sourced 
with  the  data  needed  for  warning  generation.  Conversely  the  communications 
management  system  naturally  provided  audio  generation,  audio  mixing,  etc. 

Therefore  the  voice  warning  generation  function  was  partitioned  to  the  ■  ommuni cat  ions 
management  unit,  and  the  warnings  handling  logic  was  partitioned  to  the  waveform 
generators.  This  resulted  in  a  minimal  bus  load,  since  only  a  few  data  words 
were  needed  to  specify  the  required  warning  message  and  its  status  from  the 
waveform  generator  to  the  communications  audio  management  unit. 
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In  examining  locations  for  the  bus  control,  executive  control,  display  management 
and  symbol  generation  functions,  there  were  several  possible  choices.  The 
most  obvious  way  was  to  combine  the  bus  control  and  executive  control  functions 
in  a  single  equipment  and  the  display  management  and  symbol  generator  functions 
in  a  separate  equipment.  However  from  analysis  of  databus  traffic  it  was  shown 
that  the  databus  traffic  could  be  significantly  reduced  by  combining  all  four 
functions  into  a  single  equipment.  It  was  also  shown  that  by  using  a  single 
equipment  significant  savings  in  weight,  volume,  cabling,  power  and  cooling 
would  result  and  finally  it  was  established  with  potential  suppliers  that  this 
solution  was  viable.  Thus  a  specification  for  a  waveform  generator  which  undertook 
all  four  functions  was  put  out  to  tender. 

In  this  specific  case  the  main  operational  software  which  included  the  bus 
control  transaction  tables,  executive  control,  warnings  and  display  management 
functions  were  produced  by  BAe  while  other  software  functions  for  bus  control 
algorithms,  symbol  generation,  built-in  test  and  basic  system  operating  modules 
were  produced  by  the  equipment  supplier.  This  combination  of  software  within 
individual  processors  was  satisfactorily  achieved  through  the  use  of  common 
software  standards  and  tools. 

It  must  be  recognised  that  the  system  design  processes  described  here  are  neither 
simple  not  has  it  been  possible  to  cover  all  the  aspects  in  this  paper.  Considerable 
design  effort  was  provided  in  parallel, by  equipment  engineers  and  other  disciplines. 
However  the  basic  planning,  the  design  steps  and  the  use  of  the  formal  design  method 
CORE  all  resulted  in  an  unambiguous  set  of  system  requirements  which  would  not  have 
been  produced  by  conventional  techniques.  These  enabled  the  design  to  be  successfully 
implemented . 

6 .  SYSTEM  MANAGEMENT  AND  CONTROL 


The  structured  design  process  with  its  pre-defined  life  cycle  stages  provided  the 
basis  for  the  management  and  control  strategy.  Each  life  cycle  stage  had  a  specified 
start  point,  purpose  and  resultant  output.  Thus  as  the  life  cycle  unfolded  the  successful 
completion  of  these  outputs  provided  management  with  the  necessary  measure  of  progress 
and  achievement. 

The  management  control  procedures,  to  which  ail  life  cycle  stage  products  were  subjected 
can  be  summarised  as  follows:- 

Review 

Configuration  Control 

Change  Control 

Configuration  Status  Accounting 

6 . 1  Review 

The  aim  of  the  review  process  was  to  ensure:- 

a  satisfactory  completion  of  one  stage  of  the  life  cycle  before  commencing 

the  next, 

the  correct  planning  for  successful  implementation  of  subsequent  stages. 

The  review  itself  comprised  a  technical  review  and  a  separate  management  review. 

The  former  checked  for  technical  accuracy,  compliance  with  previous  stage  and  conformance 
to  standards.  Since  the  majority  of  the  lifecycle  products  were  generated  in  machine 
readable  form,  automated  checking  procedures  were  used  to  assist  in  validating  compliance 
with  previous  higher  level  stages  and  proving  technical  accuracy. 

The  technical  review  was  a  formal  process  and  all  remedial  actions  were  recorded 
in  the  form  of  a  review  report.  In  addition  an  independant  quality  control  report 
was  also  produced.  All  such  products  from  the  technical  review  and  the  reviewed  item 
were  passed  onto  the  management  review.  This  latter  review  ensured  that  all  required 
actions  identified  and  recoided  at  t<:»chnical  review,  were  implemented  in  an  accuracte 
and  timely  manner  and  that  adequate  resources  were  availaoie  zo  impleiiieti L  the  following 
stages . 

6 . 2  Configuration  Control 

Following  a  successful  review  the  items  were  subjected  to  formal  configuration  control. 
At  this  point  the  item  ceased  to  be  the  property  of  the  author  and  became  a  project 
item.  All  formal  distribution  of  the  system  life  cycle  products  was  performed  via 
configuration  control.  Thus  all  recipients  knew  that  the  work  could  proceed  against 
a  formally  established  and  controlled  baseline.  Any  subsequent  change  to  such  baselines 
were  therefore  communicated  to  all  affected  parties  in  a  controlled  authorised  manner. 

As  a  consequence  the  work  of  each  life  cycle  stage  was  initiated  against  configuration 
controlled  baselines  from  the  previous  stages. 
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Configuration  control  was  imposed  from  the  first  product-  of  the  first  stage 
of  the  life  cycle  and  maintained  throughout  its  entirety.  Obviously  as  the  life  cycle 
unfolded  and  more  detailed  design  work  was  pursued/  previous  work  was  exposed  to  close 
scrutiny  and  errors  were  detected. 

To  accommodate  such  design  iterations,  for  whatever  reason,  an  effective  change 
control  procedure  was  rigorously  maintained  as  part  of  the  configuration  control  process. 

6 . 3  Change  Control 

All  configuration  controlled  items  were  subjected  to  a  rigorous  change  control  procedure. 
This  is  particularly  important  in  an  'integrated  system'  since  a  single  change  in  one 
area  can  cause  changes  to  several  processing  elements  elsewhere  in  the  system.  Thus 
before  approval  was  granted,  on  any  change,  all  potentially  affected  areas  were  canvassed 
for  their  comments  on  the  change  implication  including  effects  on  system  design,  timescales, 
manpower  effort  and  costs  etc.  All  aspects  of  the  change  process  therefore  involved 
the  project  as  a  whole  rather  than  individual  areas  and  for  this  reason  the  change 
process  was  managed  by  and  co-ordinated  by  an  independent  configuration  control  group. 

This  ensured  that  the  correct  procedures  were  enforced  and  that  all  relevant  data  was 
obtained  so  as  to  make  the  necessary  valued  judgement  as  to  whether  the  proposed  change 
should  be  authorised  for  implementation.  In  certain  cases  formal  reviews  were  held 
if  the  change  was  in  any  way  controversial  or  extensive.  No  changes,  however  small, 
were  allowed  to  be  implemented  without  formal  approval  via  the  agreed  procedures. 

In  addition  to  managing  the  change  process,  the  configuration  control  group  also 
monitored  and  assessed  the  change  process.  Each  change  was  uniquely  identified  and 
categorised  in  order  to  formulate  change  statistics.  These  records  provided  a  high 
level  of  visibility  to  management  into  how  the  project  was  progressing.  On  EAP  it 
was  clearly  evident  that  the  adopted  design  approach  had  proved  invaluable  in  laentifying 
the  majority  of  errors  in  the  early  design  stages  where  they  were  most  easily  and  cheaply 
corrected,  i.e.  in  the  design  paperwork  rather  than  in  the  defined  product.  This  experience 
suggests  that  management  should  expect  to  see  a  large  amount  of  change  in  progress 
throughout  these  early  life  ycle  stages  which  only  decreases  as  the  systems  testing 
stages  are  reached.  This  volume  of  change  during  the  design  process,  whilst  desirable, 
poses  significant  problems  which  can  only  be  contained  with  the  strict  aherence  to 
configuration  control  procedures  and  the  maintenance  of  configuration  status  accounting. 

6 . 4  Configuration  Status  Accounting 

In  a  project  with  a  large  number  of  configuration  controlled  items  and  an  even  larger 
number  of  changes  in  progress,  the  status  accounting  of  these  items  becomes  essential. 

All  project  participants  must  be  kept  informed  on  a  frequent  and  regular  basis  about 
the  current  status  of  all  configuration  items,  i.e.  their  issue  number  and  all  applicable 
authorised  changes  to  that  issue.  This  process  is  merely  the  communication  of  current 
design  data  baselines  to  all  parties  involved  in  the  furtherance  of  the  systems  design 
in  accordance  with  those  baselines.  A  configuration  status  report  also  communicates 
progress  and  achievement  to  project  management.  This  report  covered 

overall  progress 

a  list  of  all  configuration  items,  their  issue  and  change  status 

all  new  items  subjected  to  configuration  control 

all  new  issues  of  items  indicating  embodied  changes 

all  new  changes  including  their  status 

change  analysis  data. 

7.  OBSERVATIONS  AND  CONCLUDING  REMARKS 

The  use  of  the  structured  design  approach  together  with  its  associated  tools  undoubtedly 
contributed  to  the  success  of  the  EAP  in  designing  the  avionics  system  to  a  high  standard 
in  an  extremely  short  timescale.  Th^  following  specific  points  are  considered  to  be 
worthy  of  note  in  summarising  what  was  learnt  from  this  exercise  and  in  providing  pointers 
to  the  design  of  future  weapon  systems. 

-  The  structured  approach  together  with  the  application  of  the  rigorous  management 
and  control  procedures  enabled  realistic  programme  plans  to  be  produced  and  provided 

a  high  level  of  visibility  to  management  in  terms  of  progress  of  the  design  activities. 
The  change  statistics  proved  to  be  a  valuable  indicator  of  how  the  project  expectations 
and  requirements  were  being  fulfilled. 

-  The  undertaking  of  a  freeze  of  the  system  requirements  prior  to  starting  the  functional 
analysis  process  and  then  the  application  of  a  strict  configuration  control  procedure 
which  virtually  eliminated  the  introduction  of  changes  to  these  requirements  once 

the  freeze  had  taken  place  were  considered  to  be  majo.  factors  in  enabling  the 
programme  timescale  to  be  met. 

-  The  use  of  the  structured  approach  brings  about  a  significant  increase  in  the  a,  ount 
of  design  documentation  produced,  however  this  is  greatly  assisted  by  the  use  of 
computer  aided  tools  which  reduce  the  labour  intensive  nature  of  this  task.  This 
increase  in  design  documentation  is  a  significant  step  forward  in  overcoming  past 
deficiencies  of  having  insufficient  information  readily  available.  It  also  significantly 
reduces  such  tasks  as  the  production  of  test  specifications,  customer  manuals  etc. 


--  The  key  to  the  production  of  a  high  quality  system  design  was  undoubtedly  the  insistence 
'  on  the  adherence  to  the  very  rigid  control  and  management  of  the  design  process 
and  the  use  of  the  automated  validation  tools.  CORE  proved  to  be  a  very  powerful 
tool  not  only  for  design  but  also  for  fault  finding  due  partly  to  the  extensive 
documentation.  This  was  found  to  be  very  versatile  in  assisting  the  engineers  to 
rapidly  locate  the  problem  area  and  correct  it.  It  also  enabled  changes  in  the 
requirements  to  be  introduced  easily  and  rapidly. 

~  The  structured  approach  to  the  total  system  desigrv  places  more  responsibility  on 
the  weapon  system  contractor  who  carries  out  the  partitioning  process,  and  therefore 
determines  where  and  how  the  various  functions  will  be  carried  out.  How  much  of 
the  resulting  activity  is  undertaken  by  the  weapon  system  contractor  or  the  avionic 
equipment  suppliers  is  a  matter  of  debate.  It  is  considered  that  avionics  suppliers 
will  continue  to  Implement  the  specialist  functions  such  as  sensors,  displays  and 
processor  hardware  but  the  definition  of  the  on-board  software  will  become  the  respon¬ 
sibility  of  the  weapon  system  contractor. 

-  As  well  as  the  tools  associated  with  SAPRA  which  were  used  to  assist  in  the  design 
of  SAP  systems,  use  was  also  made  of  mainframe  text  processors,  minicomputer  word 
processors,  standard  proforma  and  data  base  tools.  For  future  projects,  the  extension 
to  a  comprehensive,  centralised,  computerised  engineering  database  is  considered 

to  be  highly  desirable. 

-  In  any  project  there  is  a  need  for  effective  configuration  control  throughout  the 
design  phase.  On  EAP  this  was  handled  by  manual  means  supported  wherever  possible 
with  computer  aids.  As  the  size  of  the  project  increases  and  the  use  of  a  centralised 
engineering  data  base  with  multi-user  access  is  established,  so  automated  configuration 
control  tools  must  be  available. 

-  It  is  considered  that  complex  system  requirements  cannot  be  accurately  described 
in  plain  'english'  text.  The  use  of  tools  such  as  CORE  generate  their  own  design 
language  and  introduce  a  need  for  training  not  only  of  the  system  design  engineers 

but  of  all  the  personnel  who  will  be  associated  with  the  project  such  as  test  engineers, 
support  engineers  and  in  particular  managers  and  representatives  of  the  Customer. 

-  A  major  difference  between  the  structured  'top-down'  approach  compared  to  existing 
'bottom  up'  approaches,  is  the  elapsed  time  before  some  functioning  of  the  system 
can  be  seen.  In  the  latter  case  it  is  usual  for  some  areas  of  the  system  to  become 
visible  early  in  the  programme,  but  in  the  former  case  the  system  tends  to  come 
together  all  at  once,  albeit  on  time. 

In  conclusion  it  must  be  admitted  that  there  were  doubts  during  the  initial  stages 
of  the  project  as  to  whether  the  structured  design  approach  was  sufficiently  developed 
to  enable  us  to  achieve  our  declared  objectives.  In  retrospect  the  success  of  the 
project  in  achieving  35  flights  in  its  first  30  days  with  no  requirements  for  system 
rhanges,  shows  that  the  doubts  were  unfounded.  In  particular,  the  success  of  the  structured 
design  approach  applied  to  the  avionics  system  in  terms  of  the  quality  of  design,  the 
timescale  achieved  and  its  supportability  were  beyond  our  expectations  and  Indicates 
the  way  forward  for  the  design  of  the  more  complex  weapon  systems  of  the  future. 
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DISCUSSION 


P.Simoiis,  US 

Do  the  software  tools  for  this  process  support  multiple  decompositions  of  a  functional  analysis? 

Author’s  Reply 

Figure  3  of  the  paper  shows  that  hardware  assignment  or  design  occurs  at  the  end  of  stage  3  of  system  design,  after  the 
global  system  and  subsystem  functions  have  been  identified.  System  design  is  driven  by  mission  and  phase  of  flight 
requirements.  Decomposition  at  stage  2  (see  Figure  3  of  paper)  identifies  subsystem  requirements  at  the  attack,  flight 
control,  display  and  control,  etc.,  levels.  This  includes  all  mission  requirements.  Particular  mission  analysis  can  be 
performed  at  this  point,  including  the  system's  offensive  and  defen.sive  abilities.  The  system’s  defensive  abilities  are 
generally  compromised  in  the  UK  because  of  the  requirement  to  use  existing  equipment  provided  to  the  aircraft 
constructor  by  the  government. 


G.Bouche,  GE 

Do  you  know  about  national  or  NATO  activities  aimed  at  standardization  of  system  design  t(K>ls  such  as  CORE? 

Author’s  Reply 

We  are  not  aware  of  any  national  or  NATO  activities  to  standardize  system  design  tools.  Within  British  Aerospace, 
there  is  an  intent  to  standardize  on  CORE.  For  EFA.  the  customer  requires  CORE/'EPOS  to  be  used  throughout  the 
design.  This  requirement  is  driving  CORE/EPOS  as  a  common  project  (EFA)  design  tix)l. 
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by 
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SUMMARY 

A  new  generation  systems  architecture  being  developed  at  IBM  in  Owego.  NY,  is  designed  to  bridge  the  gap  between  today's  I55.V 
based  systems  and  the  fauH-lolerant,  totally  integrated  systems  of  tomorrow  This  paper  describes  a  no'-n  ':p«'-oach  to  system  func¬ 
tional  area  partitioning  and  the  design  of  this  generic  distributed  real-time  architecture.  The  architecture  incorporates  new  military 
standards  in  development 

INTRODUCTION 

Next-generation  avionic  systems  cannot  be  developed  by  traditional  means.  The  simulation  of  a  centralized  architecture  system 
and  the  gradual  replacement  of  the  simulator  with  the  prime  system  ‘black  boxes’  during  development  is  a  discipline  well  suited  for 
today's  technology-based  systems.  The  architecture  of  test  beds  supporting  the  development  of  future  avionic  systems,  however,  must 
map  onto  the  architecture  of  the  system  being  developed,  both  hardware  and  software.  A  distributed  fault-tolerant  system  with  parallel 
execution  ai]d  dynamic  task  allocation  to  processors  cannot  be  simulated  by  a  centralized  sc^uential  architecture. 

The  architecture  of  the  Advanced  Systems  Development  Laboratory  (ASDL)  at  IBM  Owego  is  designed  to  emulate  systems  of  the 
future  on  commercial  hardware.  Validated  system  designs  can  then  be  hardened  with  little  risk. 

The  ASDL,  presently  m  concept  validation  phase,  employs  a  fully  distributed,  data  driven  architecture.  It  is  a  hierarchically  con¬ 
trolled  parallel  pipeline  of  alternating  layers  of  self-contained  Ada*  tasks  and  a  communication  architecture  based  on  next-generation 
military  standards. 

The  decomposition  of  this  next-generation  system  required  innovative  approaches  and  a  new  way  of  thinking  when  the  require¬ 
ments  were  partitioned  into  functional  areas  of  manageable  subparts. 

FUNCTIONAL  AREA  PARTITIONING 

The  objectives  used  to  guide  partitioning  of  the  ASDL  into  functional  areas  were  reusability,  flexibility,  and  extcndibilitv 
Application-unique  requirements  were  isolated  by  extracting  generic  services  applicable  to  all  systems,  and  this  resulted  in  an  architec¬ 
ture  partitioned  into  four  functional  areas  as  shown  in  Figure  I . 

The  application-specific  requirements  were  allocated  to  the  Simulation  Models  Functional  Area  and  Data  1  ranslation  l-unciional 
Area  and  the  generic  system  services  to  the  Communications  Functional  Area  and  the  Fixccmion  Coniro.  Functional  .\rca. 
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Figure  1.  ASDI.  Functional  Areas 
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Traditionally,  sysiem-levci  functional  area  partitioning  maps  onto  hardware.  In  the  ASDL.  system  partitioning  transcends  conven¬ 
tional  hardware  and  software  boundaries.  Figure  2  shows  the  ASDL  mapping  of  functional  areas  onto  one  hardware  node  in  the  dis¬ 
tributed  architecture.  Application  modules  and  part  of  execution  control  are  at  the  top.  and  layers  of  the  communications  architecture 
are  below. 
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Figure  2.  ASDI.  Node  Functional  Area  Mapping 


SIMULATION  MODELS  FUNCTIONAL  AREA 

Mission-unique  functions  have  been  allocated  to  the  Simulation  Models  Functional  ,',rea  (SIM  FA).  SIM  FA  is  a  collection  ol 
application-specific  Ada  modules,  each  of  which  accomplish  one  self-contained  task.  The  software  interface  to  these  modules  is  stan¬ 
dardized  to  allow-  any  number  of  modules  to  be  merged  together.  Combinations  of  niirdules  emulate  entities  ranging  in  size  from  small 
subsystems  to  large  complex  systems  of  the  future. 

Intermodule  communication  at  this  level  in  the  architecture  is  logically  independent  of  hardware  allocation  and  supported  b>  the 
underlying  system  services.  Task  execution  is  externally  initiated. 

Thus,  through  system-level  partitioning,  application-  or  mission-specific  functions  were  isolated.  System  adaptation  or  changes  are 
limited  to  adding  deleting  or  upgrading  SiMFA  modules  for  software. 
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DATA  TRANSLATION  FI  NCTIONAL  AREA 

Application-unique  hardware  interfaces  have  been  allocated  to  the  Data  Translation  Functional  Area  (DATFA).  The  DATFA 
translates  the  standard  intra-ASDL  digital  formal  to  from  analog,  synchro,  discrete,  or  whatever  the  specific  need  may  be.  DATFA 
also  converts  data  to  formats  required  for  specific  data  buses.  The  first  ASDL  DATFA  implementation  is  a  token  passing  ring  to  1553 
gateway.  This  gateway  will  allow  for  hybrid  systems  during  the  transition  period  into  next-generation  military  architectures 

The  mam  ASDL  development  efforts,  however,  are  focused  on  the  generic  subsets  of  the  architecture:  the  Communications  Func¬ 
tional  Area  and  Execution  Control  Functional  Area 

COMMUNICATIONS  FUNCTIONAL  AREA 

The  Open  Systems  Intercunnnection  Reference  Model  of  the  International  Standard  Organization  (ISO)  was  evaluated  for  applic¬ 
ability  to  the  development  of  the  ASDL  communications  architecture.  Its  seven-layer  model  defines  the  partitioning  of  the  communica¬ 
tion  services  between  heterogeneous  end  users  in  an  open  network  type  system. 

The  types  of  communication  services  required  for  a  real-time  distributed  system  differ  significantly  from  those  of  an  OSI  applica¬ 
tion  non-real-time  system  as  do  the  requirements  for  the  implementations.  A  large  percentage  of  the  data  in  real-tim**  applications  is 
sensor  data  sampled  periodically  as  often  as  sixty  times  per  second. 

To  establish  virtual  circuits  beforehand  and  retransmit  erroneous  Jaia  for  reliability  is  neither  needeu  nor  desired  if  new  data  will 
be  available  in  16  milliseconds.  The  processing  overhead  of  the  comiTiunicaitons  protocol  may  require  more  time  than  that. 

The  requirement  for  a  high-speed  implementation  of  a  completely  connectionless,  unacknowledged  datagram  service  is  one  area 
where  military  distributed  real-time  systems  differ  from  traditional  systems.  Naturally,  military  systems  also  require  the  reliability  of  a 
connection-oriented  service  with  application-level  acknowledge  for  mission  implementation  and  system  execution  control 

The  implementation  of  these  services  has  different  design  drivers.  For  real-time  systems,  as  the  name  implies,  reducing  the  time 
required  for  a  task  to  communicate  with  another  is  a  primary  design  driver,  thus  minimizing  (he  end-to-end  delay  through  the  system 

The  implementation  of  the  AbDL  communciaiions  architecture,  however,  does  lake  advantage  of  the  OSI  philosophy  and  struc¬ 
ture.  Partitioning  the  services  into  layers  of  separate  entities  provides  flexibility  that  allows  change  Changing  or  adding  to  a  function  in 
one  layer  wilt  not  ripple  through  the  system.  The  impact  of  the  change  will  be  confined  to  the  one  entity  being  changed. 

In  order  to  implement  efficient  real-time  communication  services,  the  communication  protocols  of  the  .ASDL  architecture  have 
been  partitioned  into  three  layers: 

•  Lower  Layer  {!  O  Driver) 

•  Middle  Layer  (Communications  Control) 

•  Upper  Layer  (Application  Communications). 

LOWER  LAYER 

The  lower  layer  is  the  I  O  Driver,  and  it  includes  the  !  O  device  or  LAN  (I.oca!  Area  Network)  hardware  The  LAN  technology 
chosen  is  a  high-speed  token  passing  ring.  It  allows  for  distributed  control,  deterministic  access,  and  delays  that  are  quantifiable  and 
minimum  between  geographically  dispersed  nodes. 

In  the  prototyping  facility,  the  LAN  used  is  an  80Mb  s  token  passing  ring  manufactured  by  Proteon  Inc.  and  employs  a  round 
robin  type  access  method.  The  lower  layer  and  the  interface  to  it  were  designed  with  provisions  which  will  make  it  easy  to  replace  the 
layer  when  hardware  becomes  available  for  the  next-generation  military  standard  token  passing  ring.  (This  new  standard,  defined  for 
fault-tolerant  distributed  real-time  systems,  was  developed  by  the  SAE-AE9B*  subcommittee  and  is  presently  going  through  the  ap¬ 
proval  cycle.) 

The  I  0  device  hardware  contains  high-speed  input  and  output  buffers  and  a  state-machine  that  controls  the  interface  to  the  com¬ 
munications  media.  The  host  computer  is  interfaced  via  the  CPU  internal  bus. 

The  primary  function  performed  by  the  lower  layer  software  is  to  move  data  between  the  host's  internal  memory  and  the  input 
output  buffers.  There  is  little  intelligence  m  this  layer;  it  does  not  determine  n«emor>  address  or  type  data  move.  It  repons  errors  or 
anomalies  in  the  lower  layer  or  the  transmission  media  to  upper  layers  for  action,  but  it  does  no  error  handling. 

MIDDLE  LAYER 

The  middle  layer.  Communications  Control  (Com  Cntl).  controls  all  node  external  communications 

For  incoming  data.  Com  Cntl  analyzes  the  header  of  the  packet  before  data  is  moved  from  the  input  buffer  on  the  I  O  device 
Based  on  the  data’s  logical  source.  Com  Cntl  defines  memory  destination  for  the  data.  The  type  of  operation  for  the  1  O  Driver  to 
perform  is  defined  in  the  header  Message  Category  word  and  initialization  tables.  This  can  be  queue  algorithm,  using  DMA. 
programmed  I/O.  etc.,  to  move  the  data  to  another  I  O  device  for  gateway  or  bridge  functions,  or  Com  Cntl  can  direct  the  1  O  device 
to  discard  the  data  if  it  is  no  longer  required 

For  outgoing  data.  Com  Cntl  performs  the  logical  source  to  physical  destination  address  translation  and  prepares  the  packet 
header  before  directing  the  I/O  device  to  transmit  the  data.  This  address  translation  is  a  selt<ontained  entity  that  can  easily  be 
removed  when  the  MIL-STD  token  ring  is  integrated,  since  it  supports  logical  addressing  in  the  hardware. 

In  order  to  reduce  the  end-to-end  delay,  data  is  only  moved  once  as  it  passes  through  .he  communciaiions  architecture,  and  that 
move  is  between  host  memory  and  the  high-speed  input  output  buffers  in  the  1,  0  device.  Buffer  pool  techniques  are  used  to  sequen¬ 
tially  pass  control  of  access  to  the  data  from  the  application  onto  the  upper  layer,  to  the  middle  layer,  and  to  the  lower  layer  of  the 
communications  architecture. 
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UPPER  LAYER 

The  upper  layer,  Application  Communication  (App  Com),  controls  all  communications  internal  to  a  node. 

Logical  addressing  is  used  throughout  the  system  such  that  a  task  never  knows  where  another  task  that  it  communicaies  with  ib 
located  physically.  App  Com  thus  has  the  responsibility  to  define  whether  data  generated  within  a  node  is  required  by  another  task 
within  the  same  node,  or  if  control  of  the  data  is  to  be  passed  to  Com  Cntl  for  subsequent  transmission  to  another  physical  node 

All  (ask  communication  management  has  been  allocated  to  App  Com.  Each  task  resident  at  a  node  has  a  corresponding 
communication  management  task  in  this  layer.  This  App  Com  task  is  responsible  for  receiving  and  keeping  track  of  all  data  required  h> 
an  application  for  execution.  For  instance,  if  an  application  requires  data  from  one  micrnal  source  and  two  external  sources,  App  C  om 
will  take  access  control  of  the  data  as  it  arrives,  and  when  all  necessary  data  is  received,  access  control  will  be  passed  and  the 
application  task  posted  for  execution. 

As  mentioned  earlier,  military  real-time  systems  require  two  classes  of  communication  services;  a  connnectionless  datagram  type 
service,  and  an  application-level  acknowledged  message.  In  the  ASDL  architecture,  the  application-level  acknowledge  is  supported  m 
App  Com.  App  Corn's  communications  management  includes  waiting  for  acknowledgement  to  transmission  oi  these  tvpes  of  messagcv 
for  a  predetermined  period  of  time,  retry  of  message  transmission,  and  alerting  system  services  il  no  response  is  received.  App  Com  also 
provides  system  services  with  logically  named  error  messages  from  the  other  layers  for  initiation  of  programmable,  user-defined  error 
handling/  reporting  tasks. 

LAYER  INTERFACE 

Key  to  the  implementation  of  the  ASDL  architecture  is  the  design  of  the  layer  interface.  The  structure  of  the  interface  has  been 
standardized  to  allow  near  indefinite  flexibility  and  extendibility.  Functions  may  be  added  or  deleted  from  a  layer  without  aflecting 
other  entities.  Actually,  ihc  sliuciuie  and  implementation  of  the  layer  interface  permits  enure  Uyers  to  be  added.  >1  icquucd.  loi 
additional  non-reai-time  services. 

The  layer  interface  is  designed  utilizing  the  OSI  concept  of  Service  Access  Points  (SAP).  SAPs  are  memory  pointers  shared  bv 
entities  which  communicate  with  each  other  across  a  layer  interface.  Communications  via  the  SAPs  occur  in  the  following  mai.ner  An 
entity  wishing  to  operate  on  an  entity  in  an  adjacent  layer  prepares  a  control  word  defining  operation  type  and  parameters  required  loi 
the  operation.  A  memory  pointer  to  the  control  word  is  then  loaded  into  (he  specific  SAP.  and  CPU  control  is  passed  over  the  layer 
boundary.  The  receiving  entity  reads  the  SaH.  finds  the  pointer  (o  the  control  word,  and  then  decodes  the  control  word  to  pciiorm  the 
desired  operation. 

Each  layer  hcur.dary  trar.s;t;ori  cosu  CPU  iittiv  <iiid  <»dds  to  the  end-to-end  delay  of  the  system  In  the  ASDL  architecture 
prototype,  the  design  of  the  layer  interface  was  focused  on  speed  and  resulted  in  a  fast,  efficient,  and  flexible  impiementaiion 

In  the  data-driven  system  architecture  prototype,  there  are  two  SAPs  between  each  1  O  Driver  and  Com  Cntl  and  two  SAI^ 
between  Com  Cntl  and  App  Com.  one  each  direction  of  operation.  IN  or  OUT  Figure  depicts  the  layer  interfaces  with  associated 
SAPs  and  operation  direction.  Communications  occur  in  both  directions  over  a  SAP.  Any  one  operation  mav  require  •.  -vqucnce  ol 
control  words  and  responses  to  be  communicated  via  the  SAP. 

Direction  of  operation  is  defined  by  who  operates  on  whom;  that  is.  who  initiates  the  operation  For  the  implementation  o(  the 
data-driven  architecture,  this  means  r^r  '»ny  given  message  arriving  at  a  node  via  the  token  passing  ring,  lirsi  the  1  O  Driver  will 
operate  on  Com  Cntl.  then  Com  Cntl  operates  o.:  App  Com.  which  in  turn  may  operate  on  the  application  task  For  an  out  operdiion. 
the  sequence  of  operations  is  reversed  except  for  the  application  task 

By  definition,  only  control  tasks  can  operate  on  another  entity;  mission-specific  tasks  get  operated  on  and  respond. 

The  ASDL  interface  design  allows  flexibility  in  allocation  of  communications  architecture  between  mam  processor  and  I  O  proc¬ 
essor,  Communication-intensive  applications  may  require  a  separate  I  O  processor  within  the  node,  but  lor  low  to  normal 
communication  needs,  this  processing,  or  any  layer  of  it.  can  easily  be  moved  to  the  main  processor. 

EXECUTION  CONTROL  FUNCTIONAL  AREA 

In  the  ASDL  implementation.  SAPs  are  not  only  nuclei  of  communications  but  also  of  control.  Any  operation  can.  at  the  inict- 
face.  be  halted,  resumed,  or.  for  debug  purposes,  single  stepped.  This  allows  a  total  integration  of  operation  management  and  control 
functions  with  the  communications. 

Operation  management  and  control  is  one  of  the  system  tasks  allocated  to  the  Execution  Control  Functional  .\rca  (XT  A)  o!  th-. 
ASDL  architecture.  The  design  supports  standard  control  access  points  via  the  SAP  implenicntation  such  that  all  or  any  ot  the  lavers 
of  the  architecture  or  application  tasks  can  individually  be  executed  under  XFA  control  algorithms.  These  algorithms  can  he  dynami¬ 
cally  changed,  depending  on  system  state.  A  straight  mission  priority  data-driven  task  scheduling  algorithm,  for  instance,  can  be 
replaced  with  a  best  effort  decision-based  algorithm  for  temporarily  degraded  system  states  during  fault  recovery  when  onlv  partial 
data  sets  may  be  available  for  processing. 

This  task  scheduling  algorithm  decision  task  is  a  subset  of  the  overall  resource  management  task  resident  in  XFA.  Other  tightlv 
integrated  subsets  include  redundancy  management  and  anomaly  reaction 

.XFA  contains  a  hierarchical  control  structure  with  some  subsets  tesident  at  all  nodes  all  the  time.  These  subsets  include  local  node 
states;  that  is.  dynamically  updated  resource  status  data  bases  defining  tasks  allocated  to  said  nodes  and  their  communication  needs 
and  execution  state,  as  well  as  any  locally  detected  anomaly  condition. 

XFA  tasks  on  the  next  level  of  the  hierarchy  can  be  resident  at  any  node  but  need  v>nly  be  resident  at  one  for  more  dependent  on 
level  of  redundancy)  at  any  given  time.  The  resource  allocator  task,  for  instance,  queries  other  nodes  for  processing  load  b>  reading  the 
local  resource  status  data  bases  via  a  roll  call  before  making  any  task  configuration  changes. 

The  system  anomaly  handier  task  is  also  resident  in  this  next  higher  level  of  the  XFA  hierarchy  A  combination  of  periodic  health 
checks  from  the  individual  nodes  and  anomaly  reports  from  the  local  XF.A  anomaly  handlers  provides  for  automatic  reconfguraiion  in 
the  event  of  failures. 
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OBJECT  NOTATION 
OPERATION  (AND  DIR. ) 
CONTROL  PATH 


Kigurc  y.  ASDl  Architecture  Service  Access  Points  and  Control  Paths 

The  extent  of  system  automation  is  operator  defined.  XF.A  is  also  where  the  user  interlaces  with  the  system.  Here,  the  task  parti¬ 
tioning  between  man  and  machine  can  be  dynamically  changed  at  any  point,  depending  on  such  priorities  a.s  mission,  salet^ .  or 
security. 

The  user  defines  what  events  he  she  would  like  reported  in  real  lime  lor  operator  intervention  and  what  events  can  be  handled 
automaticaUy  by  the  system.  These  user-defined  programmable  instructions  aie  tightly  integrated  in  the  hierarchical  control  structure 
XKA  resident  control  states,  in  conjunction  with  the  SAPs  in  the  communications  architecture,  gate  svstem  commands  to  be  executed 
and  prevent  nonauihorircd  receniion  of  messages 

Data  bases  and  their  management  are  also  alkHrated  to  XFA.  This  includes  both  the  distributed  dynamicallv  updated  fused  sensor 
slate  and  resource  status  data  bases  and  the  mam  library  of  system  available  functions.  A  menu-driven  interface  allows  user  fncndlv 
acces.s. 

CONCLUSION 

The  ASDL  architecture  prototyping  facility  consists  of  commercial  minis  and  super-mints  connected  via  a  fiber  optic,  high-speed 
token  passing  ring,  as  well  as  special  purpose  Al  processors  and  other  arithmetic  units,  tightly  integrated  with  a  high  fidelity,  one-man 
cockpit  and  oui-ihe-window  displays. 

Early  development  focused  primarily  on  the  communications  architecture  and  the  implementation  of  a  high-speed  layer  interface 
During  the  next  year,  prototyping  of  the  system  design  will  continue  with  XFA  for  a  total  validation  of  the  concepts,  and  optimi?ation 
of  the  integration  of  system  controls  with  the  communications. 

The  ASDL  architecture  in  development  at  IBM  Owego  will  allow  evaluation  of  advanced  avionic  architectural  concepts  and  favili 
tate  the  phased  implementation  of  next-generaiton  systems. 
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The  intent  of  this  paper  is  to  succintly  outline  the  philosophy  employed  by  Agusta  during  the  deve¬ 
lopment  and  testing  of  the  EHlOl  integrated  avionic  naval  helicopter.  The  paper  is  written  following  the 
building  blocks  of  the  avionic  under  test  (see  figure  below  on  which  the  avionic  architecture  is  showfi'. 

1.  SYSTEM  DESCRIPTION 

The  EHlOl  avionic  system  is  divided  into  two  main  processing  areas:  the  Aircraft  Management  System 
(AMS),  and  the  Mission  Avionic  System  (MAS). 


FLIGHT 

DISaAY 
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The  Aircraft  Management  Syetem  conalata  of: 

Two  redundant  Aircraft  Management  Computara  (AMC):  l.a.,  one  active,  the  other  in  back-up  mode. 

Two  Senaor  Interface  Unite  (SIU)  to  handle  all  the  analogue  and  dlacret  aignala  coming  to/from  the 
helicopter 'a  sensory  system. 

A  Control  Panel  (CP)  that  allows  the  pilot  to  select  operation  (automatic  or  manual)  of  the  system. 

A  Data  Transfer  Device  (DTD)  to  do  the  download/upload  exchange  from  external  equipment  such  as 
preflight  data  and  maintenance  information. 

-  Two  Common  Control  Units  (CCU)  which  permit  the  pilot  and  co-pilot  to  interact  with  the  system 
(AMS  and  MAS). 

Symbol  Generators  (SG)  manage  the  Electronic  Instrument  System  (EIS)  programed  with  the  formats 
required  for  the  display  of  navigation,  flight  and  power  systems. 

A  Navigation  Pack  which  includes  Air  Data  Unit  (AOU),  Radar  Altimeter  (RA),  Doppler  velocity,  Tacan, 
Global  Positioning  System  (GPS)  and  Inertial  Reference  Units  (IRU). 

The  AMS  performs  management  of  all  the  basic  functions  of  the  helicopter.  These  bsslc  functions  Include 
Navigation,  Maintenance,  Performence  computation.  Communication,  and  the  monitoring  of  the  helicopter 
systems  (i.e.,  rotor,  transmission,  engine,  fuel,  electrical,  hydraulics,  etc.). 

The  Mission  Avionic  System  is  based  on; 

Two  redundant  Mission  Computer  Units  (MCU),  same  concept  as  above:  active  and  back-up. 

-  Two  Common  Control  Units  (CCU)  that  allow  the  cabin  operators  to  interact  with  the  system  (AMS  and 
MAS). 

-  Common  Waveform  Units  (CWU)  to  manage  cabin  ard  pilot  tactical  situation  displays  and  tabular  infor¬ 
mation. 

Sensors  dedicated  to  perform  the  Antieubmarine  Warfare  (ASW),  Antisurface  Vessels  (ASV)  and  Electronic 
Warfare  (EW)  are  subdivided  into: 

-  Underwater  Sensors 

Sonar  subsystem 

Magnetic  anomaly  subsystems 

Surface  Sensors 

Radar  subsystem 

Electronic  Support  Measure  (ESM) 

Identification  Systems 

Interrogator  Eriend  Foe  (IFT)  Transponder 
Interrogator  Friend  Foe  (IFF)  Interrogator 
Intermediate  Bond  Transponder 

Communication  System 

Data  Link  8ubays*'em 

Armament  System 

Weapons  management  subsystem 
Store  management  subsystem 

The  two  MCU  perform  ali  the  processing  required  for  the  mission  operation,  collecting,  processing  and 
storing  tactical  informaticn  coming  from  the  Mission  Systems.  Each  of  the  two  areas  (AMS  and  MAS)  use  as 
the  main  data  transmission  medium  a  dual  redundant  HIL-STD-1553B  data  bus,  the  AMS  also  uses  ARINC  429 
lines  to  communicate  with  most  of  the  navigation  sensors  snd  the  Automatic  Plight  Control  System  (AFCS). 

2.  TEST  DESCRIPTION 

In  order  to  carry-out  the  entire  integration  and  testing  of  the  Avionic  System  four  main  phases  have 
been  identified. 

DEVSL0PM2NT 


In  this  phase  each  subsystem  or  piece  of  equipment  is  designed  and  developed  in  accordance  with  the 
avionic  system  requirements. 

TEST  PHASE  AT  SUBSYSTEM  OR  EQUIPMENT  lEVEI. 


The  assessment  with  regard  to  the  requirements  is  carried  out. 
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FIRST  INTEGRATION 


At  this  level  Integration  of  the  Aircraft  Management  Syatem  la  conducted  parallel  to  the  Integration 
of  the  Mlaslon  Avionic  Items.  Testing  of  these  Items  la  contingent  upon  computerized  structurea  called 
Rigs.  The  equipment  under  test  Is  controlled  and  atlmulated  by  these  Rigs.  The  basic  configuration  of  the 
rigs  Is  a  host  computer,  a  set  of  15S3B  and  ARtNC  429  bus  stations,  subsystem  simulators.  Input/output 
stimulators  and  control  and  dlaplay  units. 

FINAL  OVERALL  AVIOHIC  INTEGRATIOW 


At  this  point,  the  Aircraft  Management  System  and  the  Mission  Avionic  System  are  fused,  tested,  and 
validated.  Again  such  testing  la  made  feasible  by  means  of  the  Rigs.  The  above  mentioned  phases  are  con¬ 
ducted  to  achieve  the  following  goals: 

Minimize  the  number  of  prototype  flight  trials  necessary  to  test  the  Integrated  avionics. 

Reduce  the  technical  risks  associated  with  software/hardware  Integration. 

Accelerate  the  Iterative  loop  (l.e..  test/design  changes/retest)  using  suitable  test  programs  and 
resulting  data  analysis. 

-  Deploy  an  efficient  test  battery  to  execute  all  test  runs  and  cases  required  to  qualify  and  certify 
the  systems. 

Facilitate  the  Integration  of  new  subsystems,  affording  timely  responses  to  experimental  software 
and/or  hardware  modifications.  This  feature  transcends  the  design  and  development  phase.  It  will  be 
active  throughout  the  helicopter’s  life  cycle. 

Let  us  explore  each  of  these  phases  In  more  detail.  The  Alrcr.ift  Management  Syatem  avionic  test  admini¬ 
sters  four  separate  trials.  Trials  occur  at  each  of  the  following  levels: 

Aircraft  Management  Computer  Test 

The  aim  of  this  test  Is  the  validation  of  the  hardware  architecture  when  put  together  with  the  basic 
software  under  more  severe  ground  loading  conditions  than  those  encountered  during  flight.  Testing  fo¬ 
cuses  on  the  following  main  areas  of  Interest: 

-  Interface  of  15S3B*o  input/output 

-  Arbitration  of  shared  random  access  memory 

-  Degradation  of  performance  under  multiprocessor  Interference  and  interactive  conditions 
Redundancy  management- 

Tools  and  techniques  used  to  detect  errors  during  testing  are: 

Real  time  simulation 

Failure  mode  generation  In  both  software  and  hardware  Items 
Failure  analysis 

Artificial  stress  of  C.P.U.  capabilities 

Special  test  software  used  to  establish  the  readiness  of  basic  software  and  hardware  prior  phase 
activity. 

The  A.M.C.  rig  is  composed  of  15S3B  &  ARINC  429  bus  stations.  Both  bus  stations  are  remotely  controlled  by 
the  host  computer  which  provides  them  the  necessary  data  to  simulate  equipment  not  yet  available.  It  also 
monitors  and  analyzes  output  of  the  AMC  on  the  1B53B  bus  and  ARINC  429  lines. 

Sensor  Interface  Units  Test 


The  purpose  of  this  test  phase  Is  to  verify  the  proper  operation  of  the  SIU  Integration  with  actual 
sensors.  The  SIU  are  prograiaed  with  a  select  Input/output  polling  sequence;  the  sequence  having  been  per¬ 
formance  verified.  The  Input/output  data  exchange  with  the  1553B  system  can  also  be  defined,  programed 
and  verified.  Testing  focuses  on: 

-  1553B  tnput/Output  Interface 

-  Stress  Incured  whan  CPU  respond  to  different  Input/output  sequences  and  sampling  rates 
Real  time  simulation 

Failure  mode  generation  In  software/hardware  items 

-  Failure  analysis 

-  Assessing  results,  CPU  loading,  unit  also  and  timing. 
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The  SIU  is  also  tested  by  the  rig.  This  rig  is  composed  in  part  by  1553B  b'js  statior.s  which  erriulate  the 
bus  controller  commands,  monitor  and  analyze  the  SIU's  data  transactions  on  the  bus.  The  otner  component 
of  the  rig  is  the  emulator  of  the  helicopter  sensors  (i.e.,  temperatures,  pressure,  loads,  discrets, 
frequency,  etc.).  Such  items  can  also  be  gov«*i»cu  i«j»aoteiy  oy  tne  host  computer. 

Aircraft  Management  System  Test 

The  aim  of  this  test  phase  is  to  verify  correct  integration  of  the  AMC  4  SIU  (the  iunction  ol  each 
has  already  been  tested).  Major  tests  performed  are: 

Start-up  functions 

Redundancy  management  {master/slave'  in  case  of  failure 
Cross  channel  checking  function 
Maintenance  data  bases  exchange 
Bus  monitor  functions. 

The  AMS  rig  is  an  amalgamation  of  the  AMC  A  SIU  rigs.  It  consists  of  the  host  computer,  bus  stations 
(1553B  A  ARINC  429),  SIU.  emulators  (helicopter  sensors  A  navigation  subsystems),  symbol  generator,  .’FT 
display  and  common  control  unit.  It  becomes  prudent  at  this  time  to  discuss  the  navigation  emulators. 
They  are  comprised  by  a  set  of  single  board  computers  linked  to  the  host  computer  through  an  asyncron~  is 
line.  Each  single  board  computer  emulates  a  specific  navigartoa  sutcyotems  in  terms  of  timing,  prctocd. 
failure  4  signal  characterization.  The  host  computer  furnishes  on-going,  updated  data  de.-ived  fror  the 
flight  pls'^  scenario. 

Aircraft  Management  Test 

The  activities  examined  during  this  assessment  are: 

-  Hardware/Software  inter^'aces,  functions^  capabilities 
System  performances 

-  Verification  of  reversionary  modes 
Collection  of  reliability  data 

“  Optimization  of  the  download/upload  procedure 

Support  of  flight  planning 
Check  system  validity  before  flight  test. 

At  this  point  the  aircraft  management  system  rvg  gives  pr-.ority  to  mcnitoring.  acquiring,  and  analyzing 
data.  Emulation  activities  previously  provided  by  the  rig  are  no  longer  required  as  the  real  equipment 
is  now  installed.  A  Mock  description  of  the  rig  is  given  (see  the  following/  on  which  all  the  elements 
constituting  it  appear  with  their  relevant  interconnections. 


The  foregoing  described  the  A/C  Management  System  elements  oi  the  integrated  avionic..  Let  .-s  ■■-r:; 
attention  now  to  the  Mission  Avionic  System.  The  configuratlur.  under  test  in  this  prrtiof.  trie  pr:;js-.:t, 
like  its  counterpart  the  AMS,  follows  a  developme.nt  concept  of  ev«.  mcreasine  complexitv, 

ai  e  provided  (special  to-type  test  e.^uipment.  for  evaluation  of  e'luip.-oent  requiring  part:(  ..lar 
attention  li.e.,  sonar,  radar,  armament.  ESM).  The  rig  is  also  constituted  of  Host  computer,  155.'B  Bus 
stations  and  a  i.'onmon  wave-iorn)  generator  unit.  The  ng  is  tasked  with  providing  the  activities  listed 
below: 


Hardware/software  interface  integration 

System  performances  (bus  occupancy,  CPU  load,  data  security,  etc.! 

Verification  of  reversionary  modes 
Collect  reliability  4  maintainability  data 
Optimize  download/uplcad  procedure 
Support  software  validation 
Verify  build-in  test  functions 
Support  flight  planning. 

Note,  the  functions  as  outlined  in  the  precedi.ng  do  not  include  data  handling  management  of  the  tactical 
scenario  as  needed  by  the  operators.  This  job  is  performed  on  what  is  known  as  the  Mission  Software  Oe- 
velopment  Rig  (MSDR).  All  aspects  of  cperatoi-  interfaces,  data  routing,  and  the  human  factor  are  studied 
on  the  MSDR.  Off-the-shelf  equipment  (computer,  graphic  generators,  CRT,  compilers,  data  base,  etc.)  are 
used.  This  avails  the  flexibility  necessa;^  '".'r  a  ready  analysis  of  an  exis*'ing  set-up  and  i  ..s  editing. 
Th’s  mode  of  operation  is  undertaken  to  prevent  waste  ..f  manpower  during  the  on-board  software  develop¬ 
ment,  validation  4  testing  phases. 

The  development  of  the  two  systems.  Aircraft  Management  and  Mission,  is  effected  in  two  distinct  environs. 
Only  marginally  taking  into  consideration  is  the  information  interface  of  the  two  systems.  At  this  point 
consolidation  of  the  two  systems  and  their  respective  rigs  takes  place.  Synchronization  with  regard  to  a 
common  scenario,  also  occurs  at  this  juncture.  Having  achieved  merger  the  rigs  are  referred  to  as  tie 
Overall  Integration  Rig.  The  principle  activities  executed  at  this  level  are: 

Validation  of  interfaces  between  the  two  areas 

-  Initialization  functions 
Failure  modes 

System  performances 

-  Total  system  validation. 

The  Overall  Integration  Rig  is  subject  to  scrutiny  similar  to  that  of  the  Aircraft  Management  and  Mission 
stage.  The  prime  uses  of  the  Overall  Integratioti  Rig  are  to: 

Analyze  datt  captured  by  the  assigned  bus  stations 

Emulate,  in  a  dynamic  situation,  <»ny  required  subsystem  functions 

When  possible,  replay  excerpts  from  actual  flights  that  require  further  examination. 

3.  CONCLUSIONS 

As  illustrated,  the  testing  activity  is  not  incumbered  by  external  delays.  Testing  can  be  carried 
on,  as  preliminary,  by  the  use  of  emulation  capabilities  made  available  by  the  rigs.  The  EHlOl  Avionic 
Test  Activities  are  in  the  early  sta,;e,  at  present,  so  a  deep  analysis  can  not  be  conducted.  However,  it 
can  be  stated  that  tne  Agusta  EHlOl  Integrated  Avionic  test  philosophy  has  r»»spor,ded  well  to  our  needs. 
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1.1  (NU)  SUMMARY 

This  paper  provides  an  overview  of  the  Systems  Engineering  Technique  (SET) ,  a  methodol¬ 
ogy  developed  at  TBm  Federal  Systems  Division  in  Owego,  New  York.  SET  has  been  develop¬ 
ed  to  effect  improvement  in  both  quality  and  productivity  aspects  in  the  development  of 
avionics  systems.  The  methodology  synthesizes  the  best  features  of  existing  development 
methodologies  into  a  single  core  procedure  which  is  equally  applicable  throughout  tht 
systems  development  phases  of  complex  systems.  Six  key  areas  emphasized  by  SET  are  dis¬ 
cussed,  and  the  concept  of  systems  engineering  measurements  is  introduced  as  the  means 
to  evaluate  system  quality  and  productivity.  SET  is  being  applied  to  the  development  of 
avionics  systems  at  IBM  Owego  and  has  proven  to  be  effective  in  improving  specification 
quality. 

2.1  (NU)  INTRODUCTION 

Two  major  aspects  of  development  that  must  be  addressed  by  a  systems  engineering  method¬ 
ology  are  quality  and  productivity.  Quality  concerns  the  effectiveness  of  the  system  in 
meeting  the  requirements.  Productivity  concerns  the  effective  use  of  resources  in  sys¬ 
tem  development.  Tools  to  manage  resources  and  automate  time-consuming  or  manually 
impossible  tasks  contribute  to  productivity  in  the  development  effort.  The  use  of  stan¬ 
dardized  models  and  procedures  is  a  key  element  of  both  quality  and  productivity;  reuse- 
able  components  is  another. 

Methodologies  which  address  these  issues  are  by  no  means  in  short  supply.  What  does 
seem  to  be  lacking  today  is  <i  methodology  which  addresses  all  of  the  key  elements  influ¬ 
encing  system  quality  and  productivity  throughout  the  system  development  phases. 
Figure  1  describes  the  system  development  phases,  the  associated  program  review  points 
and  the  system  engineering  specifications  developed  for  each  program  review. 
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Figure  1.  (NU)  Systems  Engineering  Development  Phases 

SET  was  developed  in  an  effort  to  synthesize  all  of  the  best  methodologies  within  a 

practical  framework  equally  applicable  throughout  each  phase  of  the  systems  development. 

As  a  result,  SET  places  emphasis  in  six  key  areas.  They  are: 

•  Use  of  three  information  models  to  develop  the  syste:.  to  the  fullest  extent  pos¬ 
sible  within  each  incremental  level 

•  A  combination  of  top-down  and  bottom-up  approaches  which  allows  for  parallel  de¬ 
velopment  of  requirements  and  design 

•  Integration  of  the  engineering  disciplines  in  all  aspects  of  the  systems  engineer¬ 
ing  process 

•  A  repetitive  procedure  that  is  applied  t^  each  incremental  level  of  system  defini¬ 
tion 


•  Use  of  a  plan  to  manage  and  coordinate  each  incremental  level  of  system  definition 

•  A  tightly  controlled  exit  from  each  incremental  level  of  system  development 

These  key  areas  provide  for  tighter  control  over  the  systems  development,  both  within 
and  between  incremental  levels  of  system  definition.  Three  of  these  key  areas  are  ad¬ 
dressed  within  each  incremental  level  and  provide  a  mote  fully  developed  system  through 
the  use  of  models  and  processes  which  maximize  involvement  of  the  engineering  disci¬ 
plines  and  customer, 

3.1  (NU)  AN  INCREMENTAL  LEVEL  OF  SYSTEM  DEFINITION 

In  2ach  incremental  level  of  system  definition,  SET  provides  for: 

•  Use  of  three  information  models  to  develop  the  system  to  the  fullest  extent  possi¬ 
ble  within  each  incremental  level 

•  A  combination  of  top-down  and  bottom-up  approaches  which  allows  for  parallel  devel¬ 
opment  of  requirements  and  design 

•  Integration  of  the  engineering  disciplines  in  all  aspects  of  the  systems  engineer¬ 
ing  process 

SET  employs  three  models  to  develop  each  incremental  level  of  the  system.  The  three 
models  are  the  functional  model,  the  physical  model  and  the  operational  model.  The  pur¬ 
pose  of  the  functional  model  is  to  refine  the  customer's  requirements  into  functional 
areas  that  make  the  system  definition  and  development  manageable.  Given  a  set  of  system 
functions,  the  physical  model  is  used  to  develop  a  physical  implementation  (design)  that 
is  feasible.  A  feasible  design  is  one  that  can  be  built  within  the  technology,  cost  and 
schedule  constraints.  A  feasible  design  is  also  maintainable,  reliable  and  supportable. 
The  purpose  of  the  operational  model  is  to  take  the  functional  requirements  and  the 
physical  design  for  an  incremental  level  and  test  them  for  suitability.  A  suitable 
system  is  one  that  satisfies  the  customer  performance  requirements,  is  useable,  is 
maintainable  and  is  reliable.  Figure  2  provides  a  summary  of  the  three  models. 


•Suitable  ••FeasiWe 

•  Meets  customer  performance  requirements  •  Available  technology 

•  System  is  usable  •  Reasonable  cost 

•  System  can  be  maintained  •  Maintainable 

•  System  is  reliable  •  Reliable 

Figure  2.  (NU)  Three  Systems  Engineering  Models 

The  development  of  the  three  models  is  an  iterative  process.  Each  model  has  ihs  own 
unique  purpose  and  overlaps  the  other  two.  As  each  model  is  developed,  it  may  impact 
the  previous  model.  Therefore,  the  development  team  must  cycle  between  each  of  the 
three  models  until  the  impacts  of  one  model  on  the  other  two  are  minimized  or 
el iminated. 

3.1.1  (NU)  THE  FUNCTIONAL  MODEL  (REQUIREMENTS  DEVELOPMENT) 

The  functional  model  allows  the  development  team  to  collect  requirements  into  groups  so 
that  intellectual  control  can  be  maintained  over  the  system  development.  Each  incremen¬ 
tal  level  has  its  own  criteria  for  developing  these  functional  groups.  For  example,  in 
the  first  level  of  system  definition  the  system  segments  and  their  interfaces  are  iden¬ 
tified.  In  the  next  incremental  level,  tlie  segment  components  (hardware  and  software) 
and  their  interfaces  are  identified,  and  so  on.  An  incremental  level  of  the  system 
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cannot  be  developed  without  taking  a  forward  look  into  the  lower  levels  of  system 
detail.  In  other  words,  the  system  must  be  developed  top-down  but  should  be  influenced 
uy  the  bottnm-up  detail.  The  functional  model  allows  the  development  team  to  look 
ahead  into  the  lower  level  system  details.  That  detail  is  then  abstracted  into  a 
consistent  set  of  requirements  that  meet  the  objectives  of  a  given  incremental  level  of 
system  definition. 

As  higher  level  requirements  are  abstracted  from  the  detail,  the  systems  engineers  take 
advantage  of  the  engineering  disciplines  and  reusability  concepts.  For  example,  when 
developing  the  functional  areas  for  a  software  specification,  the  systems  engineers  use 
the  guidance  of  the  software  development  engineers  to  ensure  the  functional  requirements 
are  suitable  for  their  development  of  the  low  level  design.  In  addition,  the  software 
development  engineers,  in  conjunction  with  the  systems  engineers,  will  identify  and 
utilize  reusable  components  from  similar  systems  that  were  develnped.  Th«a 
cojnponencs  reduce  the  cost  and  the  time  necessary  to  develop  follow  on  systems  of  a 
similar  type. 

Each  incremental  level  of  the  system  involves  a  look  ahead  from  an  existing  level. 
Since  the  requirements  from  the  present  level  drive  the  next  level  of  system  definition, 
a  traceable  link  is  established  from  one  incremental  level  to  the  next.  This  allows 
traceability  of  the  lowest  level  requirements  back  to  the  origina’’  requirements  from  the 
customer.  Figure  3  is  a  typical  example  of  the  application  if  the  functional  model  to 
an  avionics  system. 
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Figure  3.  (NU)  Avionics  System  Functions 


As  indicated  in  the  figure,  lower  level  requirements  for  the  system  are  developed  by 
analyzing  each  customer  requirement.  These  lower  level  requirements  are  then  collected 
into  functional  areas  using  the  criteria  that  is  app*.*opriate  for  the  incremental  level 
being  developed  (e,g.,  identifying  the  system  segments  when  developing  the  system  level 
specification) .  Each  function  is  shown  in  Figure  3  with  a  lic»t  of  detailed  requirements 
that  were  used  to  develop  that  functional  area.  The  customer  requirements  that  drive 
each  functional  area  are  shown.  For  example,  the  Navigati'^n  functional  area  is  driven 
by  customer  requirement  1,  the  Target  Acquisition  function  is  driven  by  customer  re¬ 
quirement  2  and  the  Control  &  Display  function  is  driven  by  both  customer  requirements. 
These  functional  groups  are  now  considered  in  the  physical  model. 


3.1.2  (NU)  THE  PHYSICAL  MODEL  (DESIGN) 


The  physical  model  allows  requirements  definition  and  design  to  proceed  in  parallel. 
Therefore,  requirements  definition  is  no  longer  a  separate  activity  from  the  system  de¬ 
sign.  Instead,  the  design  is  considered  during  the  requirements  definition  without 
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locking  in  the  design  detail  too  early.  The  objective  of  the  physical  model  is  to 
determine  if  there  is  a  feasible  design  that  can  be  used  to  implement  the  functional 
requirements.  In  making  this  determination  the  development  team  must  consider 
technology,  cost,  maintainability,  reliability  and  availability  of  the  physical 
components.  All  of  these  criteria  must  be  satisfied  to  make  a  solution  feasible.  In 
considering  the  alternatives,  the  services  of  the  various  engineering  disciplines  are 
employed.  System  architects,  hardware  engineers,  software  engineers,  reliability 
engineers  and  maintainability  engineers  are  needed  to  determine  feasibility.  The 
feasibility  question  is  asked  and  answered  at  each  incremental  level  of  system 
development.  When  developing  the  system  specification,  the  team  must  select  the  system 
segments  that  are  feasible  for  the  system  under  development.  If  the  system  segment 
specifications  are  being  developed  the  group  must  select  the  segment  components 
(hardware,  software  and  operators)  that  are  feasible  for  each  segment.  This  process  of 
selection  then  imposes  additional  constraints  on  the  lower  levels  of  design. 

Figure  4  illustrates  a  design  used  during  the  development  of  an  avionics  system  at  IBM 
in  Owego,  N.Y.  The  physical  design  consists  of  multiple  processors,  memory  stores  and 
data  busses.  This  design  was  selected  due  to  the  nigh  degree  of  parallel  activities  the 
system  must  perform  to  meet  the  overall  performance  requirements.  An  important  question 
at  this  point  is  how  should  the  functional  processing  requirement  groups  (developed  with 
the  functional  model)  be  allocated  to  the  physical  processors?  This  question  can  be 
answered  by  considering  the  functional  requirements  and  physical  design  in  the 
operational  model . 
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Figure  4.  (NU)  Physical  Design  for  an  Avionics  System 
3.1.3  (NU)  THE  OPERATIONAL  MODEL 

The  operational  model  requires  support  from  a  variety  of  engineering  disciplines  who 
provide  analysis  of  system  performance,  reliability,  maintainability  and  operability. 
This  analysis  is  used  to  determine  whether  the  functional  requirements  and  physical  de¬ 
sign  are  suitable.  Bach  incremental  level  of  system  definition  is  deemed  suitable  if 
the  functional  requirements  and  physical  design  form  a  system  that  meets  performance 
requirements,  is  useable  by  the  operators,  is  maintainable,  and  is  reliable.  This  is 
accomplished  by  mapping  the  functional  areas  and  the  physical  components  in  a  time 
ordered  sequence  to  model  the  system  performance,  reliability  and  maintainability, 
operational  flow  diagrams,  derived  from  a  mission  scenario,  are  developed  that  allocate 
the  funccions  to  the  physical  components.  These  operational  flow  diagrams  represent 
system  tasks  that  are  stimulus/response  oriented.  The  stimuli  that  can  cause  system 
tasks  to  be  initiated  are  the  operator  initiated  stimulus  (operator  depresses  a  key), 
the  event  initiated  stimulus  (receipt  of  messages  on  a  data  link  or  hardware  inter¬ 
rupts)  ,  and  the  cyclic  stimulus  (computing  navigation  position  at  a  25  hertz  rate) . 
Once  system  tasks  are  identified,  the  flows  that  affect  system  performance,  processor 
loading,  operator  workload,  system  reliability  and  maintainability  are  developed.  The 
flows  are  then  individually  analyzed  to  see  how  a  single  tasl^  effects  processor  loading, 
data  bus  loading  and  system  performance.  These  individual  flows  are  then  used  in  a 


mission  scenario  to  continue  performing  trade  studies  at  a  pyetem  level  and  to  further 
refine  the  requirements.  The  types  of  analysis  performed  and  required  disciplines  are 
detailed  in  Table  1. 


Analysis 

Dieciplirws 

1 .  Allocation  of  performwice  to  functional  araas 

Systems  Engineers.  Software  Engineers.  Hardware  Engineers 

2.  Altocatton  of  function  to  phystcal  dements 

Systems  Er>gineers.  Software  Engir>eefs,  Hardware  Engir>ears 

3.  Operator  and  System  workload  analyM 

Systems  Engineers.  Software  Engineers.  Hardware  Engirteers. 

K'jma.'s  Factors 

4.  System  Testability 

Systents  Engineers.  Test  Engineers 

5  System  Maintainability  and  Reliability 

Systems  Engineers.  Maintainabitity.  Integrated  Logistic 

Suf^rt,  RetiabUitv 

Table  1.  (NU)  Operational  Analysis  and  Discipline  Support 

Figure  5  illustrates  a  mission  scenario  and  two  lower  level  system  tasks  that  need  to  be 
performed  during  the  engagement  phase  of  the  mission.  Note  that  the  two  tasks  have  an 
over’ap  indicating  that  there  is  a  need  for  parallel  processing.  As  indicated  in  the 
figure,  the  functional  processing  has  been  allocated  across  the  physical  components.  In 
addition,  performance  has  been  allocated  to  the  functions  to  meet  an  overall  performance 
requirement  for  the  system.  Computer  based  tools  can  now  be  used  to  analyze  each  task 
individually.  Figure  6  illustrates  an  analysis  of  the  Missile/Rocket  Solution  and  shows 
that  processor  number  2  is  89.2%  loaded  with  just  this  single  task.  This  indicates  that 
the  allocation  of  function  to  the  physical  components,  in  this  case,  may  not  be  optimal. 
Tools  can  assist  in  the  reallocation  of  function  by  automatically  analyzing  alternate 
allocations  of  functions  to  the  physical  components.  This  analysis  technique  can  now  be 
extended  to  the  entire  system  by  modeling  all  tasks  that  are  performed  at  any  point  :.n 
the  mission  scenario.  Figure  7  illustrates  the  Missi ie/Rocket  Solution  task  run  in 
combination  with  the  Gun  Pointing  Solution  task.  Note  that  there  was  a  reallocation  of 
function  such  that  processor  2  is  loaded  at  54.6%. 


MIssito/Rocket  Solution 


Operator  selects 


Gun  Pointing  Solution 


Figure  5.  (NU)  Operational  Analysis  of  the  Functional  and  Physical  Approaches 
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Missile/Rocket  Solution 
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Figure  6.  (NU)  Computer  Analysis  of  the  Missile/Rocket  Solution  Task 


Combined  Missile/Rocket  Solution 
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Figure  7.  (NU)  Computer  Analysis  of  the  Missile/Rocket  Solution  Task  in  Combination 
with  the  Gun  Pointing  Solution  Task. 

Once  the  functional  requirements  and  physical  design  are  determined  to  be  suitable  using 
the  operational  model,  the  incremental  level  of  the  system  development  has  been 
completed.  An  assessment  of  the  overall  system  to  date  is  made,  and  the  iterative 
development  process  then  begins  again. 

4 . 1  (NU)  THE  SYSTEM  DEVELOPMENT  PHASES 

SET  establishes  control  over  the  system  development  chases  by; 

•  Use  of  a  repetitive  procedure  that  is  applied  to  each  incremental  level  of  system 
definition 

•  Use  of  a  plan  to  manage  and  coordinate  each  incremental  level  of  system  definition 

•  A  tightly  controlled  exit  from  each  incremental  level  of  system  development 

To  develop  complex  systems,  it  is  advantageous-  to  use  a  methodology  which  is  essentially 
the  same  for  each  level  of  the  incremental  development  of  the  system,  since  it  is  impor¬ 
tant  that  one  incremental  level  flow  smoothly  into  the  next.  This  can  only  be  effected 
through  clearly  defined,  standardized  models  and  procedures  which  pick  up  development 
where  the  last  iteration  leaves  off. 

Figure  1  shows  major  systems  engineering  specification  activities  throughout  the  system 
development  phases  of  a  program.  Each  increment  of  system  definition  has  a  unique  set 
of  activities  and  objectives  culminating  with  a  system  level  review  milestone.  SET 
applies  the  same  core  procedure  iteratively  at  each  inciement  of  system  definition. 
This  procedure  is  based  upon  the  use  of  the  three  models,  and  is  specialized  via  a  set 
of  development  criteria  suited  to  meet  the  objectives  of  the  individual  increment. 

SET  employs  a  Systems  Engineering  Management  Plan  (SEMP)  to  control  the  overall  system 
development  process.  The  management  plan  provides  for  control  over  the  technical  de¬ 
velopment,  the  engineering  specialty  integration,  and  the  iterative  systems  engineering 
development.  Since  SET  features  clearly  defined  end  points  for  each  incremental  level, 
the  iterative  development  of  the  system  can  be  crisply  controlled  by  a  management  plan. 
Just  as  the  military  standards  provide  for  baseline  control  points  via  the  system  level 
reviews,  SET  provides  control  points  via  the  inspections  between  the  system  review  mile¬ 
stones.  The  inspection  provides  a  controlled  exit  to  ensure  that  all  aspects  of  the 
system  have  been  developed  before  the  next  incremental  level  of  the  system  is  defined. 


It  is  utilized  to  review  technical  correctness,  to  review  and  update  schedules  and 
plans,  and  to  baseline  the  system  at  the  current  level  of  development. 

At  the  completion  of  each  incremental  development  level,  SET  procedures  include  an 
evaluation  step  which  involves  the  use  of  systems  engineerinq  measurements.  These 
measurements  are  assessments  of  both  the  system  being  developed  and  the  method  being 
used.  SET  procedures  specify  an  evaluation  step  for  assessment  in  two  measurement  cate¬ 
gories:  quality  and  productivity.  Quality  measurements  serve  to  evaluate  the  effec¬ 
tiveness  of  the  system  in  meeting  the  requirements.  Productivity  measurements  serve  to 
evaluate  the  effective  use  of  available  resources  in  developing  the  system. 

5 . 1  (NU)  SYSTEMS  ENGINEERING  MEASUREMENTS 

The  systems  engineering  measurements  are  viewed  by  SET  as  an  integral  part  of  the  de* 
veiopmenc  process.  ‘ine  tormalization  of  systems  engineering  measurements  is  a 
relatively  new  effort  and,  to  date,  the  measurement  of  quality  has  received  the  most  em¬ 
phasis.  SET  developers  are  currently  focused  on  clearly  defining  systems  engineering 
measurements  for  both  quality  and  productivity  aspects  of  development,  along  with  their 
respective  nominal  values.  This  ability  to  evaluate  the  system  development  process  pro¬ 
vides  SET  developers  with  information  which  can  be  used  to  refine  the  methodology  it¬ 
self  . 

Measurements  are  taken  and  evaluated  both  within  an  incremental  development  level  and 
throughout  the  system  development  phases.  For  each  incremental  level,  the  measurements 
are  directed  toward  measurement  of  the  system  as  it  exists  at  that  particular  point  in 
development.  Throughout  the  system  development  phases,  a  synthesis  of  measurements  is 
an  ongoing  process,  necessary  in  evaluation  of  the  system  as  a  whole.  When  a  measure¬ 
ment  is  identified  as  being  less  than  optimal,  the  source  of  the  problem  is  identified 
as  the  customer,  the  user,  or  the  systems  engineering  organization.  If  the  source  is 
systems  engineering,  an  improvement  to  the  process  is  effected.  If  the  source  is  the 
customer  or  the  user,  the  measurements  provide  a  vehicle  for  discussion  of  the  problem. 

One  measurement  currently  used  to  track  specification  quality  is  the  number  of  para¬ 
graphs  changed  in  the  specification  against  the  major  program  milestones.  Since  the 
cost  of  fixing  errors  increases  over  time  (see  Figure  8) ,  a  desirable  trend  in  the  data 
should  be  a  constantly  decreasing  number  of  errors  found  over  the  system  development 
phases.  Initial  data  indicates  that  SET  is  making  a  difference  in  specification  quali¬ 
ty.  Figure  9  is  a  plot  of  paragraphs  changed  for  a  Software  Requirements  Specification 
(SRS)  on  two  programs  developed  at  IBM  in  Owego,  New  Yorx.  Although  the  avionics  sys¬ 
tems  were  different,  they  were  developed  by  essentially  the  same  team  of  engineers  and 
were  of  the  same  order  of  magnitude  (125,000,  i6-bit  words) .  The  data  shows  that  the 
specification  developed  with  SET  (Program  B)  is  a  marked  improvement  over  the  specifi¬ 
cation  that  was  developed  before  SET  was  available  (Program  A) . 


Cost  o1  Changes  versus  Program  Phase 
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Figure  8. 


Conceptual  Validation  Development  Production 

(NU)  Cost  of  Fixing  Errors  Versus  Program  Phase 
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Percentage  of  Paragraphs  Changed 


Control  Points. 

Point  1  Changes  made  between  release  of  the  specification  by  Systems  Engineering  and  completion  of  design 
by  Software  Engineers 

Point  2.  Changes  made  between  completion  of  software  design  and  iab  test 
Point  3.  Changes  made  between  iab  test  and  formal  demonstration 

Figure  9.  (NU)  Systems  Engineering  Measurement  Date 


DISCtlSSION 


P.Siinons,  US 

( 1 )  How  is  the  tool  mechanized,  and  where  can  I  learn  more? 

(2)  What  criteria  are  used  in  the  early  stages  for  the  physical  model? 


Author’s  Reply 

( I )  PSL/PSA  is  used  for  recording  and  analyzing  the  functional  requirements.  A  PC-based  tool  is  used  for  the 
operational  mode!  ojialysio.  Tliio  PC  baaed  tool  *3  ondcr  dovolopmci**  unu  *3  prugiam  uinquc  mi*  pomi.  1 1.** 
more  information,  contact  Bruce  Radloff,  Manager.  Sysfem.s  Engineering  Technology.  IBM.  Owego.  NTV'  (607) 
751-2121. 


(2)  Early  in  system  definition,  criteria  are  derived  by  considering  the  mission  scenario(s)  and  first-level  functional 
requirements.  If  there  is  no  existing  hardware,  new  hardware  is  specified.  Careful  consideration  must  be  given  to 
the  state  of  the  technology,  or  predicted  technology  in  this  case. 


P.Aouad,  CA 

( 1 )  What  is  the  typical  time  span  of  the  development  cycle? 

(2)  What  is  the  time  span  to  develop  the: 

•  Functional  model? 

•  Physical  model? 

•  Operational  model? 

Author's  Reply 

( 1 )  An  average  of  6  to  8  weeks  is  needed  for  each  level  of  system  definition.  Less  time  is  needed  initially .  and  more 
lime  is  needed  at  the  lower  levels. 

(2)  It  is  difficult  to  assign  specific  limes  to  each  model,  since  the  process  is  not  serial.  The  development  team  will 
typically  alternate  between  the  models  until  their  impacts  on  each  othe*’  arc  minimized  or  eliminated.  The  lime  to 
develop  each  model  also  depends  on  the  system.  For  example,  a  system  built  using  off-the-shelf  hardware  requires 
less  time  in  the  development  of  the  physical  model  than  one  requiring  new  hardw  arc. 


J.Shcpard,  UK 

You  mentioned  the  use  of  PSL  PSA  to  store  data  from  the  models.  You  also  said  that  the  models,  apart  from  the 
functional  model,  were  manual,  not  automated.  How  are  these  data  entered  into  PSl.  PSA?  Do  you  have  an  automated 
capture  technique? 

Author’s  Reply 

The  data  on  past  programs  were  entered  manually  using  templates  resident  on  a  computer  or  on  paper.  A  database 
entry  technician  enters  the  information  into  the  database.  Functional  requirements  are  then  automatically  produced 
from  the  database.  We  have  a  prototype  tool  that  allows  the  engineer  to  construct  an  information  flow  diagram.  From 
this  diagram,  the  tool  automatically  produces  PSL  templates. 


G.Bouche,  GE 

Is  your  procedure  an  engineering  goal  for  future  systems  engineering  tasks,  or  did  you  already  complete  a  practical 
project  using  the  procedure?  If  so.  what  type  of  project  was  it? 

Author’s  Reply 

The  procedure  has  been  u.sed  on  Combat  Talon  IL  V-23.  and  LHX/ARTl.  We  use  this  procedure  on  all  of  the  avionics 
programs,  and  it  is  becoming  our  division  standard.  We  also  have  a  three-day  workshop  on  its  use. 


W.H.McKinlay,  UK 

( 1 )  With  what  level  of  detail  and  flexibility  are  scenarios  defined? 

(2)  How  do  you  verify  that  the  correct  match  between  man  and  .sen.sor.s/systcms  is  achieved? 

Author's  Reply 

( 1 )  Initial  mis.sion  .scenarios  are  defined  to  the  extent  necessary  to  understand  the  system  characteristics  and  its 
environment.  Many  scenarios  may  1  necessary.  All  flows  in  the  operational  model  are  derived  from  the  initial 
mission  scenarios  and; 

•  Are  operator-initiated. 

•  Have  critical  performance  requirements  (e.g..  timing  and  accuracy). 

•  Affect  .system  loading,  operator  loading,  and  .system  mmling. 

(2)  The  operator-initiated  flows  and  flows  that  affect  the  operator  workload  allow  us  to  establish  the  relationship 
between  the  operator  and  the  system. 


MAQUETTAGE  DES  SPECIFICATIONS  FuNCTIQNNELLES 
DU  LOGIC I EL  EMBARQUE 
EXPERIENCE  DU  SYS7EME  AVIQNIQUE  RAFALE 


Monsieur  Patrick  SCHIRLE 

Ingfenieur  d'^tudes  i  la  direction  g^nferale  technique 

AVIONS  MARCEL  DASSAULT 
78.  Quai  Marcel  Dassault 
92  SAINT-CLOUD  -  FRANCE 


RESUME 

Le  developpement  du  logiciel  des  syst^s  avioriques  requiert  une  documentation  de  specification 
fonctionnelle  abondante  et  souvent  contractuel le.  Le  enaquettage  de  ces  specifications  pemet  : 

-  d'ameiiorer  la  qual ite  forme] le  des  specification:  (coherence,  compietude,  lisibilite) 

-  de  r6aliser,  tres  tot  dans  le  cycle  de  vie,  une  validation  fonctionnelle  des  specifications 
sur  simulateur  (miroir  de  la  specification) 

-  de  fournir  des  elements  de  recette  (jeux  d'essais)  aux  realisateurs  de  sous-ensembles  du 
systeme 

-  de  disposer  d'une  reference  fonctionnelle  conmode  lors  de  Tintegration  des  materiels  reels. 

Le  maquettage  intervient  des  la  phase  de  definition  fonctionnelle  du  logiciel  selon  le  scenario 

su'vant  : 


-  premiere  ecrlture  des  specifications  fonctionnel les  du  logiciel 

-  analyse  critique  des  specifications  :  contrble  de  forme 

-  codage  des  specifications  dans  I'ordinateur  de  simulation  de  la  maquette 

-  tests  fonctionnels  sur  maquette  :  contrdle  de  fond 

-  fourniture  aux  realisateurs  des  equipements  de  specifications  reputees  bonnes  et  des  jeux 
d'essais  correspondants . 

-  realisation  du  logiciel  des  equipements 

-  integration  et  validation  du  systeme  reel 

Le  systeme  avionique  de  1' avion  RAFALE  presente  des  innovations  telles  que  Tintegration  des 
systemes  avion  (moteur,  connandes  de  vol ,  etc...)  ou  la  securisation  des  informations  de  pilotage.  Ces 
nouvelles  fonctions  entrainent  un  accroissement  et  une  evolution  qualitative  notables  du  logiciel  des 
calculateurs  embarques. 

Pour  ameiiorer  la  qualite  et  le  deiai  de  mise  au  point  des  logiciels,  le  developpement  s'est 
appuye  sur  une  methodologie  integrant  le  maquettage  des  specifications  fonctionnelles  du  logiciel. 

La  maquette  a  ete  construite  autour  d'un  calculateur  $EL  supportant  le  codage  Fortran  des  3500 
pages  de  specifications  fonctionnelles  du  systeme. 

Chaque  specificateur  a  pu  valider  sa  specification,  puis  globalement  Tensemble  des 
specifications,  directement  sur  maquette.  A  cette  fin,  un  conversationnel  specifique  a  du  etre  developpe 
pour  permettre  la  stimulation  du  logiciel  maquette  et  Texploitation  des  resuUats  grace  i  des  scenarios 
repr6sentatifs  des  conditions  d'utilisation  du  systeme  reel. 

Outre  le  gain  realise  pour  1 ' integration  du  systeme  reel,  la  maquette  a  pu  etre  utilisee  comme  : 

-  support  d'analyse  de  pannes 

-  banc  d'essais  pour  les  evolutions 

-  generateur  d'eiements  de  recette 

-  reference  fonctionnelle  pour  les  intervenants 

1  -  INTRODUCTION 

Les  systemes  avioniques  actuellement  developpes  par  la  Societe  des  Avions  Marcel  Dassault  se 
caracterisent  par  : 

-  Une  complexite  croissante 

-  Une  integration  de  plus  en  plus  serree  de  leurs  fonctions 

-  Une  inflation  chronique  du  volume  de  logiciel  embarque. 

Ceci  Implique  la  coordination  des  travaux  de  tres  nombreux  specialistes  et  une  organisation 
industrielle  adequate  ;  face  i  ces  probiemes  et  pour  assurer  la  qualite  constante  du  produit,  la 
solution  actuellement  retenue  par  Tavionneur  consiste  en  la  definition,  la  mise  en  place  et  le  suivi 
d'une  methodologie  stricte  concernant  le  developpement  du  systeme,  particul idrement  du  logiciel 
emba  rquT^ 
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Cette  methodologie  precise  sans  ambiguity  que'les  sont  les  etapes  du  d^veloppement.  les  produits 
et  les  responsabll  it^s  qui  leur  sont  attaches.  Li6e  au  traditionnel  cycle  de  vie  du  logiciel,  elle 
fait  apparaitre  des  phases  de  rcnception/sp^cif ication ,  de  realisation  (codage)  et 
d’ int&gration/val idation. 

La  phase  de  conception/sp^cif ication  se  revile  comme  ^tant  la  plus  critique.  En  effet, 
s'inscrivant  dans  la  partie  amont  du  cycle  de  vie,  toute  erreur  ou  imperfection  a  ce  niveau  est 
amplifi&e  au  cours  du  cycle  et  se  traduit  par  des  consequences  avale^  couteuses  et  difficilement 
maitrisables . 

De  plus,  les  produits  issus  de  cette  phase  etant  essentiel lement  des  documents  papiers,  la 
perception  du  produit  final  a  travers  ces  simples  documents  est  delicate  et  probldmatioue. 

Les  deux  etapes  maitresses  de  la  phase  de  conception/sp^cif ication  sont  : 

-  L'etape  de  specification  qlobale  du  systSme 

-  L'etape  de  specification  fonctionnelle  detaillfte 

L'etape  de  specification  qlobale  consiste  en  I'ecriture  de  deux  types  de  documents  : 

-  Regies  geperales  :  il  s'agit  d'une  description  des  regies  et  philosophies  d'emploi  du  systeme, 
communes  3  toutes  les  missions  (principe  de  dialogue  honme-machine,  gestion/signal isation  des  pannes, 
superposition  des  fonctions  d'armes,  etc...)- 

-  Specifications  qlobales  des  fonctions  operationnelles  :  il  s'agit  de  decrire,  pour  chaque  fonctior 
specT?ique  du  systeme,  Te  scenario  nominal  d'utilfsatlon  de  cette  fonction,  en  tarme  d 'ut i 1 i sateur 
(pilote)  et  bien  entendu  dans  le  respect  des  regies  gene»-ales. 

Ce  type  de  specification,  non  exhaustif  sur  un  plan  fonctionnel  et  ne  dediant  pas  1es  roles 
respectifs  de  chacun  des  equipements,  permet  de  valider  en  terme  d'operationnel  la  conception  des 
fonctions  et  sert  de  base  a  l'etape  suivante. 

La  validation  de  cet  ensemble  de  specification  est  realis^e  pratiquement  grace  ^  un  simulateun 
simplifie  construit  autour  d'une  cabine  de  pilotage,  permettant  un  dialogue  direct  et  ais6  avec  les 
pilotes. 

L'etape  de  specification  fonctionnelle  dfetaill^e  se  compose  de  deux  taches  : 

-  Etabl issement  d’une  architecture  fonctionnelle  :  decomposition  a  priori  en  modules  des  taches  a 
rea11ser  et  repartition  de  ces  modules  dans  les  equipements  ;  principes  generaux  de  dialogue  entre 
equipements  et  entre  modules  d'un  meme  equipement. 

-  Ecriture  des  specifications  fonctionnel  les  detainees  par  module  et  par  equipement,  description 
exhaustive  des  traitements  i  effectuer  et  des  interfaces. 

Ces  documents  representent  la  dernidre  etape  de  la  phase  de  conception  directement  du  role  et  de 
la  responsab :  1  i te  de  I'avionneur  :  fTsTervTront  de  reference  cpntractuelie  vis  a  vis  des  cooperants 
pour  la  realisation^u  logiciel  des  equipements. 

C’est  3  ce  niveau  de  specification  que  nous  ressentons  un  besoin  constant  d'ameiipration  de  la 
quaHte,  tant  fonnel le  que  fonctionnelle. 

Les  methodes  dassiques  que  nous  utilisons  depuis  plusieurs  annees  pour  "valider"  ces  documents 
(representant  plusieurs  milliers  de  pages)  sont  : 

-  Canevas  strict 

-  Organisation  de  relectures  croisees 

-  Oictionnaire  de  terminologie 

-  Traitement  de  texte  (texte  +  graphique) 

Nous  tentons  actuellement  une  ouverture  vers  oes  methodes  exploratoires  plus  "up-to-date"  qui 

sont  : 

-  L 'uti 1 isation  d'un  langage  de  specification  formel  et  controle  par  outil. 

-  Le  maquettage  des  specifications  fonctionnel  les  detainees. 

Le  langage  formel  n'est  employ^  3  ce  jour  que  pour  des  applications  sp^cifiques  (Conmandes  de 
vol,  chaines  a  haute  sScuritS)  et  n'a  pu  etre  syst^matique  ;  en  effet  les  langages  actuels  sont  cibles 
S'jr  un  type  particulier  de  specification  et  requierent  une  formation  specifique.  Etant  actuellement 
trop  eloign6s  du  langage  naturel  pour  permettre  une  lecture  (ou  une  ecriture)  par  un  nombre  important 
d'individus  de  fonctions  et  ue  competences  diverses,  leur  utilisation  qucique  inevitable  a  terme,  fait 
actuellement  I'objet  d'etudes. 

Le  maquettage  fonctionnel  par  centre  presente,  outre  sa  faisabilite  demontree  par  les  methodes  et 
tactiques  actuel i es ,  1 'avantage  d'assurer  3  la  fois  la  qualite  formelle  de  la  specification  (par 
necessite)  et  la  qualite  fonctionnelle  de  la  m^me  specification  par  effet  de  miroir. 

Cette  strategie  de  maquettage  a  ete  retenue  et  mise  en  pratique  dans  le  cadre  du  programme 
RAFALE  3  l'etape  d'ecriture  des  specifications  fonctionnel les  detailiees. 
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2  -  CQNTEXTE  RAFALE  :  HYPOTHESES  ET  SPECIFICITES 


2.1  -  Evolution  des  specifications  fonctlonnelles  d^talllfees 

Pour  les  syst^s  des  premieres  enn^es  80,  il  6tait  r6a]i$6  un  unique  document  de 
specification  par  equipement,  lequel  decr-ivait  globalement  I'ensemble  des  fonctlons  de  chaque 
equipement  sans  contrainte  particuHere  de  modularlte.  Ce  document  debouchait  sur  la  realisation 
du  logiciet  equlpement  correspondant  it  toute  modification  du  premier  entrainait  ipso-facto 
modification  du  second  selon  une  gravite  variable  et  non  prevue. 

Pour  des  raisons  de  taille  et  d'evolutivite  du  logiciel  et  de  la  documentation,  11  est 
devenu  necessaire  i  partir  des  systemes  MIRAGE  2000  EXPOP’’’  d'a^fiuer  la  resolution  du  couple 
document  de  specification/logiciel  grice  i  la  creation  d'une  architecture  fonctionnelle  du 
logiciel  des  equipements. 

Cette  architecture  reprlsente  la  decoupe  en  un  certain  nombre  de  modules  independents,  des 
fonctions  i  realiser  par  le  logiciel  d'un  equipement.  Cette  decoupe,  permettant  le  cloisonnement 
entre  des  modules  bien  identifies,  s'appuie  sur  des  criteres  : 

‘  d'evolutivite  : 

modules  i  faible/forte  probabilite  d'evolution. 

Exemples  ;  forte  probabilite  ;  conversationnel  hoRine-machine 
faible  probabilite  :  algorithmes  de  balistiqua 

-  de  securite  : 

modules  de  differents  niveaux  de  criticite  {cf.  DO  178) 

-  de  recuperabilite  ;  s 

modules  specifies  comme  recuperables  d'un  systeme  i  I'autre  (module  independant^  de 
1 'environnement  spedfique  d'un  systeme  donne). 

L'architecture  fonctionnelle,  etablie  par  AMD*BA  pour  I'ensemble  des  equipements  est  prise 
en  coinpte  pour  1 'ecriture  des  specifications  et  debouche  sur  une  modularite  fonctionnelle  de  la 
documentation  et  in  fine  du  logiciel  correspondant  :  i  chaque  document  de  specification  correspond 
un  module  identifie  du  logiciel  : 

Caracteristiques  des  specifications  "modulaires"  : 

•  Chaque  module  est  specifie  par  un  et  un  seul  document  de  specification. 

-  Chaque  module  est  defini,  gere,  modifie  de  facon  autonome. 

-  Chaque  module  est  decrit  par  : 

.  ses  Interfaces  avec  les  autres  modules 
.  sa  fonction  de  transfert 

-  Chaque  module  peut  Itre  realise  de  facon  autonome 

-  Chaque  module  est  decompose  en  sous-modules  et  d  terme  en  pieces  de  logiciel. 

2.2  -  Contexte  RAFALE 

Le  systeme  avionique  de  I'avion  demonstrateur  RAFALE  presente  un  certain  nombre  de 
nouveautes  et  de  spedficites  par  rapport  aux  avions  de  la  generation  precedente,  teHes  que  : 

-  1 ' integration  tres  poussee  incluant  les  systemes  avion 

-  1 'extension  du  nombre  de  fonctions  necessaires  des  le  premier  vol 

-  la  decentralisation  des  fonctions  systeme  (reparties  dans  plusieurs  equipements) 

-  la  generalisation  de  I'emploi  des  techniques  numeriques  dans  des  domaines  ou  1 'experience  en 
etait  faible 

*  les  deiais  tres  courts  et  tres  tendus  de  1 'operation. 

Pour  faire  face  d  cette  situation,  il  a  alors  ete  decide  de  realiser  un  travail  de 
maquettage  des  specifications  avec  les  objectifs  suivants  : 

a)  Ameiiorer  la  qualite  des  specifications  fonctlonnelles  detainees 

b)  Permettre  une  validation  fonctionnelle  de  ces  specifications 

c)  Fournir  aux  cooperants  des  jeux  d'essais  coherents  pour  valider  aussi  tbt  que  possible  leurs 
developpements. 

d)  Disposer  d'un  banc  d'essai  pour  tester  a  priori  les  evolutions. 

Ce  travail  a  debute  en  Mars  85  avec  les  etapes  suivantes  : 

a)  Analyse  critique  des  specifications 

b)  Realisation  de  la  maquette 

c)  Exploitation  de  la  maquette 
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3  -  ANALYSE  CRITIQUE  DES  SPEC1FICA7I0HS 

3.1  -  But 


Les  specifications  fonctionnelles  dAtaiHees  repr#sentent  la  charniere  entre  la  conception 
{travail  AMO-BA)  et  la  realisation  des  logiciels  (travail  des  cooperants).  II  est  done  important 
qu'elles  soient  i  la  fois  : 

-  Entierement  representatives  des  besoins  operationnels  du  concepteur  (aspect  fonctionnel) 

•  Comprehensibles  et  realisables  par  les  cooperants  (aspect  formel ) 

Le  but  de  Tanalyse  critique  des  specifications  est  d'ameiiorer  leur  qualite  pour  couvrir 
1 'aspect  formel,  e'est-i-dire  s'assurer  que  les  specifications  sont  : 

-  lisibles 

<  completes 

-  coherentes  entre  elles 

-  sans  ambiguTte 

-  realisables  informatiquement 

3.2  «  Principe  et  organisation 

Un  sp6ci f icateur  etant  naturcHement  satisfait  de  son  document  grSce  a  sa  connaissance  du 
contexte  operationnel .  pour  que  1 'experience  soit  rentable  il  a  fallu  isoler  les  lecteurs 
critiques  de  ce  meme  contexte  en  limitant  les  exnl foornies  sur  les  specir  iLacions.  t.e  mot 
d’orrtre  a  etS  -  ne  pas  juger  de  ce  <^iie  doit  ^alre  la  specification  (fonctionnel)  mais  juger 
uniquement  la  maniere  dont  elle  est  ftTrite  et  sa  faisabilite. 

L'equipe  de  relecture  n'a  pas  eu  connaissance  du  besoin  operationnel  exprime  a  travers  les 
specifications  detainees  (specifications  globales  non  fournies). 

la  totalite  des  documents  de  specification  detainee  (3000  pages)  a  ete  soumise  &  l'equipe 
de  relecture  critique.  Toute  fiche  d’evolution,  quelle  que  soit  son  origine,  s’est  vue  appliquer 
la  meme  procedure  de  relecture. 

3.3  -  Resultats  de  1 'etape 

Le  nombre  de  critiques  ( justii^i^es)  a  ete  extremement  important  :  250  pages  de  remarques* 
representant  de  I’ordre  de  1000  points  precis. 

Le  nombre  de  critiques  par  page  de  specification  (dune  in  fine  la  qualite  formelle  de  la 
specification)  varie  considerablement  en  fonction  : 

-  du  redacteur  (rigoureuA/uon  rigoureux.  precis/general »  structuri/cunectiotirieui  de  details) 

-  du  module  specifie  ( logique/algorithmique) 

Les  erreurs  relevees  par  la  critique  entrent  flutes  dans  les  trois  categories  : 

-  erreurs  de  rigueur 

-  erreurs  de  general ite 

-  inadaptation  de  la  specification  I  une  realisation  informatique. 

a)  Erreurs  de  rigueur 

-  Interface  manquante  :  1  ’ information  utilisee  par  les  traitements  n'est  pas  dedaree  a  entree 
de  la  specification 

-  Interfaces  incoherentes  :  les  interfaces  dedarees  en  entree  du  module  specifie  n'existent 
pas  dans  le  systeme  (non  calcul^es  par  d’autres  modules) 

-  incompietude  des  tralt^nts 

.  Le  traTtement  relatif  I  une  sortie  dedaree  du  module  n'est  pas  specifie 
.  Dans  une  combinaison  logfque,  toos  les  cas  ne  sont  pas  renseignes  ;  il  est  a  noter  que  le 
cas  est  tres  frequent  lorsque  la  logique  est  exprimee  au  moyen  de  phrases  (si,  alors, 
sauf,  quand)  et  pratiquement  inexistant  si  la  logique  est  decrite  sous  forme  de  tableaux 
de  verite. 

.  Les  conditions  d' initial isation,  d’activation,  d'enchainement  des  traitements  ne  sont  pas 
specif iees . 

-  Terminologie  f1oue  ou  ambigUe 
Exemple  : 

"on  determinera  ..." 

"dans  la  plupart  des  cas..." 

"dans  certaines  conditions..." 

"1 ' information  existe  dans  les  cas  suivants..." 

b)  Erreurs  de  generalite 

-  Caracteristiques  d'interfaces  non  specifiees 

Ne  sont  pas  precises  I'unite,  le  type  (logique,  bcoieen),  les  valeurs  possibles  d'une 
information. 
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-  Traitement  d6cr1t  trop  qlobalen>ent  ; 

Ce  genre  d'erreur  est  frequent  lorsque  le  sp^cificateur  surestime  le  savoir  faire  (ou 

I'intultion)  des  rfiaHsateurs  de  logiciel. 

c)  Inadaptation  de  la  specification  i  une  realisation  informatique 

>  Choix  de  1a  solution  informatique  :  le  specificateur,  dans  un  louable  souci  de  rigueur 

Impose  la  ffcon  dont  doit  etre  realise  le  traitefnent  :  connaissant  peu  les  criteres  de 
"programmatlofr*^  le  choix  est  parfois  non  astucieux  et  peut  deboucher  sur  un  logiciel 
demesure  ou  non  evolutif. 

3.4  -  Remarques  et  commentaires  sur  I'etaoe  d*analyse  critique 

L'etape  d'analyse  critique  des  specifications  a  ete  extremement  fructueuse  et  reveiatrice. 
Nombre  de  probiemes  de  toute  importance  ont  pu  etre  ainsi  resolus  a  priori,  evitant  de  les 
reporter  i  la  phase  d'integration.  Par  centre,  1‘energie  mise  en  oeuvre  a  ete  egalement 

importante  :  equipe  de  relecture,  temps  "voie"  aux  specificateurs,  lourdeur  de  mise  &  jour  de  la 
documentation. 

La  plupart  des  erreurs  recensees  sont  des  erreurs  evi tables  qui  ne  remettent  pas  en  cause  le 
profil  actuel  des  specificateurs.  En  effet,  cette  phase  de  relecture  a  conduit  i  ameiiorer  une 
specification  existante,  non  pas  i  creer  une  couche  de  specification  plus  detailiee. 

Enfin,  I'experience  a  ete  vecue  par  les  specificateurs  conme  un  controle  qualite 

suppier.cnt' ii  e  done  ressentie  de  facon  tres  mitigee... 

4  -  REALISATION  SE  lA  MAQUETTE 

4.1  -  Elaboration  des  programmes-maquette 

La  necessite  de  coder  les  specifications  a  mis  en  evidence  trois  imperatifs  d'ecriture  de 
celles-ci.  Les  deux  premiers  sont  d'ordre  general  et  concernent  toute  specification  devant  etre 
codec,  le  troisieme  est  lie  i  la  structure  doubiee  du  systfeme  RAFALE. 

Premier  imp6ratif  :  compietude  des  interfaces 
Deuxieme  imperatif  ^  definition  du  type  de  chaque  variable 

Troisieme  imperatif  :  definition  pour  chaque  variable  du  type  de  liaison  entre  module  emetteur  et 
module(s)  recepteur(s) 

O'autre  part,  I'operation  de  codage  a  continue  la  necessite  de  description  d’un  logiciel 
enveloppe  pour  chd.jue  module  Implante  dans  un  equipement  double. 

Compietude  des  interfaces 

Cette  etape  est  indispensable  avant  toute  operation  de  codage.  Le  renseignement  complet  des 
interfaces  a  done  ete  necessaire,  avant  codage  du  logiciel  initial,  cortne  avant  chaque  passage 
d'une  version  i  1 'autre. 

Definition  du  type  de  chaque  variable 

Cet  imperatif  a  conduit  5  enrichir  la  base  de  donnee  d'interfaces  avec  la  definition,  pour 
chaque  variable,  d'un  type  analogue  aux  declarations  de  variables  FORTRAN,  a  savoir  : 

-  Dooleen,  tableau  de  booieens,  logique,  reel,  entier, 

Nota  :  La  phase  d’analyse  critique  des  specifications  avail  deja  fait  apparaltre  la  necessite  de 
definition  du  type  de  variable. 


Codaqe  des  modules  fonctionnels 

Les  programmes  maquette  ont  ete  ecrits  en  FORTRAN,  directement  a  partir  de  la  specification 
(apres  phase  d'analyse  critique)  et  en  utilisant  la  base  de  donnee  d'interfaces  conme  referenciel 
des  variables. 

Produits 


Le  resultat  de  la  phase  d'eiaboration  des  programmes-maquette  se  decompose  en  : 

-  Un  produit  intemediaire  sous  la  forme  d'un  fichier  de  variables  de  8  caracteres  extrait  de  la 
base  de  donnees  d'interfaces.  Ce  produit  constitue  en  fait  un  complement  de  specification, 
indispensable  pour  la  generation  du  code. 

-  Un  produit  final  compose  des  programmes-maquette  (ou  modules)  d'une  chalne  de  calcul. 
L'obtention  de  I'ensemble  des  modules  representatifs  des  deux  chalnes  devant  etre  faite  grSce  i 
la  duplication  de  ces  programmes-maquette. 


f' 
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4.2  -  Adaptation  de  la  console  de  visualisation  des  ^changes  (CVE) 

La  CVE  6ta1t,  i  I'orlglne,  un  outll  de  visualisation  des  ^changes  entre  ^qulpements 
num^riques.  Pour  les  l>eso1ns  du  maquettage,  1)  a  fallu  faire  tendre  cet  outll  de  visualisation 
vers  un  outll  de  validation  de  specifications.  Les  travaux  d’adaptation  ont  porte  sur  : 

Au  niveau  conversationnel 


-  Le  pilotage  de  la  simulation  (choix  du  mode  simulation,  des  modules  I  activer,  etc...) 

-  Le  developpement  de  procedures  d 'entree  de  valeurs  i  la  CVE 

>  L 'amei ioration  de  la  gestlon  des  chalnes  memorisees  (concatenation  de  chaines,  appel  nomlnatif 
de  celles-ci). 

-  Le  developpement  des  procedures  de  tests  automatiques 
Au  niveau  systeme 

•  La  generation  des  lexlques  CVE 

Ces  lexlques  sont  necessa'^res  au  bon  fonctionnement  de  la  simulation  et  i  rexploitation  des 
resultats  de  celles-ci. 

Ils  comprennent  : 

.  la  llste  des  modules  et  leurs  adresses 

.  la  correspondence  des  fichiers  8  caracteres  par  rapport  aux  fichlers  de  la  base  de  donnee 
d'interface  initlale  (40  caracteres) 

.  la  liste  des  paves  recepteurs  d'ure  infonnation  donnee 

4.3  -  Mise  en  oeuvre  de  la  simulation 

Les  caracterlstiques  essentielles  de  la  simulation  mise  en  place  sont  les  suivantes  : 

-  Simulation  mono-frequence 

-  Cycle  de  simulation  correspondant  i  1 'activation  sequentielle  des  modules  maquettes 

-  Prise  en  compte  de  1 'architecture  double-chaine  du  RAFALE  ; 

Cette  prise  en  compte  se  resume  5  1 *etabl issement  de  deux  procedures  : 

.  Eclatement  des  variables 
.  Duplication  des  programmes 

Afin  de  generer  1 'ensemble  des  variables  emises  et  recues  dans  les  equipements  des  chaines 
1  et  2,  il  a  ete  necessaire,  3  partir  du  fichier  standard  8  caracteres,  d'edater  les  variables 
pouvant  etre  emises  par  deux  equipements  s^nnetriques  (voir  schemas  ci-dessous). 


CHFMlNEMgV^  NON  SECURISC 
avanT  ECL*f£wesT 


*^*^£M}NEMEnT  SECURISE 

AVAnT  eCLATEnEwt 


1  1 _ 1 

A 

X  1 

B 

APRES  ECLATEmEkT 

X  2  - * 

Al 

1 

B 

A2 

1 

IOTA  I.A  VARIABLE  XO  VE  SERT  (Ju'A  SIVULER  t*  6CSTJ0H  OES 
Ef^AVSES  '’ANS  SON  ROLE  O'AIGUlLLAGE  DES  VARIABLES 
EMISES  AlTESnA  -  -V— -  Al  ET  A2 


APRES  EC>,ATEWEnT 
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RgCAPITULATIF  OES  PHASES  OE  LA  RFALISATION  MAQUETTE 


5  -  l^re  EXPLOITATION  MAQUETTE  -  TESTS  UNITAIftCS  ET  MANUELS 
Definitions  : 

Tests  unltalres  :  tests  portent  sur  les  variables  d 'Entrees/Sorties  d‘un  module  unique 
Tests  tnanuels  :  tests  pour  iesquels  les  valeurs  des  variables  d’Entrees  doivent  etre  modifiees 
manoeller:ent  par  le  specificateur. 

Le  deroulement  de  ce  type  de  test  est  le  suivant  : 

1)  Constitution  d'une  chatne 

2)  Entrde  des  valeurs  3  la  CVE 

3)  oedenchement  d'un  pas  de  simulation  et  lecture  des  rdsultats 
5.1  -  Constitution  d'une  chalne 


Cette  operation  consiste  4  sdlectionncr  un  certain  nombre  de  variables  panrii  le  total  des 
variables  d'E/S  d'un  module  donne  et  3  les  regrouper  dans  un  ensemble  appeie  chalne.  Suivant  la 
taille  de  ce  module  ce  choix  a  ete  fait  : 
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Pour  les  modules  de  talUe  Importante 

En  s61ectionnant  toutes  les  variables  <f ‘Entrfees/Sorties  se  rapportant  i  une  entity  donnfee. 
Pour  les  modules  de  tallle  rfeduite 


La  tallle  des  sous-modules  de  ces  sf^cificatlons  pertnet  d'utlliser  toutes  les  variables  de 
ces  sousHnodules  pour  constituer  les  chalnes.  Chaque  chalne  est  1' image  d'un  sous-module. 

Cette  m^thode  permet  : 

-  de  retrouver  chaque  variable  de  sortie  du  module  dans  une  chalne 

-  de  disposer  dans  chaque  chatne  de  toutes  les  informations  utilis^es  pour  ^laborer  les  variables 
6fflises  par  le  sous-mcdule. 

On  peut  ainsi  se  rapprocher  de  la  demarche  visant  i  valider  les  pieces  de  specification  de 
niveau  le  plus  bas  avant  de  passer  au  niveau  sup^rieur. 

5.2  -  Entree  des  valeurs  i  la  CVE 


Cette  operation  est  r^alis^e  en  d^signant  la  variable  h  modifier  dans  la  liste  des  variables 
de  la  chalne,  en  s^lectionnant  le  mode  “modification  de  valeur",  puis  en  entrant  la  nouvelle 
valeur. 

6ien  que  la  modification  manuelle  de  valeur  de  n'importe  quel  type  de  variable  soit 
possible,  la  plupart  des  tests  ort  port6  sur  des  modifications  de  variables  boolfeenns  VRAI/FAUX, 
et  de  variables  logiques. 

Quelques  tests  ont  portfi  sur  des  modifications  de  variables  numferiques  soit  pour  verifier 
des  logiques  (dedenchement  de  seuils,  temporisations . . . } ,  soit  plus  rarement,  pour  valider  des 
fonctions  de  transfers  numeriques. 

6  -  2eme  EXPLOITATION  MAQUETTE  -  TESTS  AUTOHATlQUES 

6.1  -  Intergt  des  tests  automatioues 

L'utilisation  des  tests  manuels  a  r^veie  plusieurs  limitations  de  ces  derniers  ; 

1)  Oifficultes  de  manipulation  des  chaines  comportant  un  nombre  important  de  variables. 

2)  Inadaptation  de  ces  tests  pour  la  recherche  de  dependances  entre  variables. 

3)  Oifficult^s  de  validation  des  mfecanismes  mettant  en  jeu  des  transitions  ou  des  m^morisations . 

Ces  limitations  ont  amen^  d  envisager  le  d&veloppc*'»nt  de  tests  automatiques  qui 
permettraient  &  la  fois  •. 

-  de  g4n4rer  automatiquement  des  combinaisons  de  valeurs  d’entr^e  pour  les  chaines  h  tester 

-  de  faciliter  I'exploitation  des  rftsultats  par  des  Witlons  appropriEes  sur  listings. 

G^n^ration  automatique  de  valeurs  d'entr^e 

Les  objectifs  vis4s  correspondent  aux  limitations  mentionnees  plus  haut  pour  I'exploitation 
des  tests  manuels  : 

-  Pouvoir  balayer  toutes  les  combinaisons  des  variables  d'entr^e  choisies  et  observer  leur  impact 
sur  toutes  les  variables  Smises  par  le  module  pour  dfetecter  d 'feventuel les  oependances  anormales 
entre  variables, 

-  Mettre  au  point  des  scenarios  nominaux  permettant  de  simuler  diff^rentes  configurations 
d'initialisatlon,  des  enchafnements  de  phases  de  vol  mettant  en  jeu  des  transitions  ou  des 
m$fflorisations, 

Les  premiers  tests  ainsi  mis  en  place  appeHs  tests  mono-variables  ont  permis  de  tester  toutes  1es 
combinaisons  dWuites  d'une  combinaison  initiale  en  faisant  verier  une  variable  boolfeenne  de  la 
chalne. 

La  validation  des  transitions  et  mfemorisations  a  donn§  lieu  a  la  creation  du  type  de  test 
"SCENARIO  DE  PANNE",  Ce  type  de  test  permet  d'introduire  a  des  intervalles  de  temps  traduits  en 
nombre  de  pas  de  simulation  des  jeox  de  valeurs  d'entr^e  prepares  3  I'avance. 

La  verification  exhaustive  de  tous  les  cas  possibles  de  valeurs  d'entr§e  d'une  chalne  de 
variables  booieennes  donn^e  a  ete  rendue  possible  grSce  aux  tests  combinatoires. 

En  tout  7  types  de  tests  automatiques  ont  ete  developpfes  : 

a)  Combinatoire  statique 

b)  Combinatoire  s^quentlel 
cj  Mono-variable  statique 

d)  Mono-variable  sfiquentlel 

e)  Aieatoire  statique 

f)  Aieatoire  sequentlel 

g)  Scenario  de  panne 

Nota  :  Un  test  statique  se  distingue  d'un  test  sequentiel  par  la  remise  de  toutes  les  variables  a 
la  valeur  d'initialisatlon  apres  chaque  pas  de  simulation. 
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Facilltfes  d'exploitation  des  rdsultats 

ParaU^lement  au  d^veloppemetit  de  ces  types  de  tests,  les  possibilit^s  de  sortie  des 
r^sultats  ont  6t6  6tendues  : 

-  Possibllitfes  d'impression  ou  non  de  U  “rfetference"  (c'est-4-dire  de  la  chalne  avec  ses  valeurs 
d'1n1t1a11sdt1on). 

-  Possibility  d'yditions  sfilectives  des  variables  ayant  varife  par  rapport  au  cycle  prycSdent. 

-  Possibility  d'yditlons  syiectives  des  variables  ayant  variy  par  rapport  i  la  combinaison  de 
ryfyrence . 

Ces  possibilltys  ont  permis  en  particuller  de  manipuler  des  chaines  constituyes  d'un  grand 
nombre  de  variables,  sans  pour  autant  avoir  i  rechercher  les  rysultats  slgnificatifs  dans  la  liste 
de  toutes  les  variables  constituant  la  chaine. 

6.2  -  Exploitation  des  tests  automatigues 

La  phase  d'exploitation  des  tests  autoffiatlques  a  dymarry  en  automne  85  et  a  comporty  deux 
parties  : 

-  Tests  unitaires  automatigues 

-  Tests  globaux  automatigues 

Tests  unitaires  automatigues 

Suivant  la  nature  de  la  spycification,  deux  types  de  tests  ont  yty  principalement  utilisys  : 

-  Tests  combinatoires 

-  Scynarios  de  panne 

Pour  les  spycifications  dycrivant  des  mycanismes  de  logique  sans  mymorisation  ni  probiymes 
d'initialisation,  la  majority  des  tests  a  yty  du  type  combinatoire  statique  (spycifications  de 
visualisations  notarnnent). 

Pour  les  spycifications  dycrivant  un  ncvnbre  important  d'ytats,  de  transitions  et  de 
temporisations,  des  scynarios  de  panne  ont  yty  gynyralement  employys  (spycification  de 
signal isatlon  des  informations  moteur  ou  coTnmandes  de  vol  notarnnent). 

Tests  globaux 

Oyfini tion 

•Test  global  :  test  consistant  4  activer  I'ensemble  des  modules  maquettys. 

Nota  :  Ce  type  de  test,  disponible  ygalement  en  mode  manuel  n*a  yty  utilisy  pratiquement  qu'en 
mode  automatique. 

XntyrSt 

L'intyryt  des  tests  globaux  est  de  valider  le  comportement  de  I'ensemble  des  modules 
maquettys . 

En  effet  cheque  spycification  peut  etre  vyrifiye  en  thyorie,  4  la  seule  lecture  du  document 
de  spycification  lui*meme. 

Par  contre,  il  n'existe  pas  de  document  dycrivant  la  rypartition  prycise  des  traitements 
entre  les  diffyrentes  spycifications  et  assurant  ainsi  que  la  mise  bout  4  bout  des  diffyrents 
modules  conduise  au  respect  de  la  spycification  globale. 

7  -  BILAN 

7.1  -  Ressources  spycifigues  mises  en  oeuvre 

L 'analyse  des  spycifications  et  leur  codage  dans  la  maquette  ont  requis  50  Homme-Hois.  dont 
prys  de  50  %  pour  la  phase  d'analyse  critique  des  spycifications.  Le  dyveloppement  de  la  chaTne 
d'outils  ainsi  que  la  mise  en  oeuvre  de  la  maquette  ont  nycessity  22  Homnes-Mois. 

Sur  le  plan  matyriel,  la  maquette  a  yty  ryalisye  sur  un  systyme  informatique  GOULD  (SEL 
32/27)  dont  il  a  yty  nycessaire  d'augmenter  la  puissance  au  cours  du  dyveloppement  en  raison  de  la 
dygradation  du  temps  de  ryponse.  11  faut  souligner  que  la  ryalisation  de  la  maquette  a  pu  se  faire 
dans  les  temps  impartis  grice  4  1 'utilisation  de  Vexpferience  acquise  Tors  de  dyveloppements 
antyrieurs  dans  le  domaine  de  la  simulation. 

7.2  -  Rypercussions  sur  la  mythode  de  travail 

L ' Introduction  du  maquettage  a  modifiy  la  mythode  suivie  pour  dyvelopper  le  logicie! 
avionique  RAFALE  par  rapport  aux  habitudes  des  programmes  prycydents.  Cette  modification  concerne 
essentiellement  ; 

-  la  dydaration  des  interfaces  entre  modules  (y  compris  modules  d'un  myme  yquipement) 

-  I'ycriture  d'une  spycification  avec  une  contrainte  de  maquettabi 1 ity 

-  la  possibility  de  voir  "vivre"  une  spycification 
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Declaration  des  Interfaces  entre  modules 


La  coherence  Impos^e  au  niveau  des  Interfaces  par  la  saisie  de  celles-cl  sur  I'outil  de  base 
de  donnees  (premidre  etape  du  maquettage)  a  induit  une  plus  grande  rigueur  dans  le  dialogue  entre 
sp6cificateurs.  En  effet  1‘obligation  de  rentrer  cheque  interface  dans  une  reference  unique  et 
regroupant  1 'ensemble  des  interfaces  a  evite  la  plupart  des  redondances  d' informations  (ou  les 
origines  d' informations  inconnues)  que  la  dispersion  des  interfaces  aurait  risque  d'entralner. 

Ecriture  des  specifications  avec  une  contrainte  de  maquettabi 1 ite  : 

La  necessite  de  decrire  des  traitements  pouvant  etre  transcrits  sans  ambiguTte  en  code 
executable  (en  1 'occurrence  FORTRAN)  a  permis  d'eviter  des  retards  dus  aux  difficuUes  rencontrees 
par  les  cooperants  dans  la  lecture  de  specifications  detainees  trop  "general es". 

Possibilite  de  voir  vivre  une  specification 

Lors  d'application  de  fiches  de  modifications,  la  possibilite  de  valider  presque 
itimediatement  celles-c1  a  permis  de  "resserrer"  le  lien  entre  le  specificateur  et  son  produit.  En 
effet,  bien  qu'il  soit  pratiquement  toujtnirs  possible  de  tester  une  modification  (ou  un  mecanisme 
de  facon  generale)  mentalement  ou  sur  le  papier,  1 'util isation  d'un  outil  accompi issant  1ui>meme 
I'effort  necessaire  i  I'execution  de  la  fonction  de  transfert  a  decharge  d'autant  le 
specificateur,  lui  permettant  ainsi  de  se  consacrer  i  1 ' interpretation  des  resultats. 

Par  centre  le  bilan  de  roperation  maquettage  fait  apparaitre  des  contraintes  ayant  limite 
Tinteret  de  celle-ci,  en  ce  qui  concerne  le  progranme  RAFALE.  Ces  contraintes  sont  de  deux 
types  : 

-  Ergonomie  de  la  maquette 

-  Oeiais  et  disponibil ite  des  utilisateurs 

Ergonomie  de  la  maquette 

Malgre  les  efforts  importants  d'amenagement  du  conversationnel  de  la  maquette,  la 
presentation  trds  desincarnee  des  informations  a  rapidement  modere  I'empressement  des  utilisateurs 
pour  ce  nouvel  outil.  II  est  en  effet  difficile  de  valider  le  comportement  d'un  ensemble  de 
reticules  (3  plus  forte  raison  d'une  page  complete  de  reticules),  &  I'aide  de  VRAI/FAUX  ou  de 
variables  logiques  codecs.  Cette  presentation  quelque  peu  rebarbative  n'a  pas  permis  d'exploiter 
compieterr.ent  1es  possibilites  pourtant  importantes  de  la  maquette. 

Delays  et  disponibilites  des  utilisateurs 


Les  periodes  de  disponibilite  des  utilisateurs  de  la  maquette  n'ont  pas  toujours  coTneide 
avec  les  periodes  oO  il  aurait  ete  le  plus  profitable  d’exploiter  celle-ci.  En  particulier  les 
tests  globaux,  interet  majeur  de  la  maquette,  n'ont  pas  eu  I'itnportance  qu'ils  auraient  du  avoir, 
en  raison  de  I'exploitation  tardive  de  ceax-ci. 

7,3  -  Repercussion  sur  la  qualite  du  loqiciel  avionique 

L'analyse  de  rimpact  du  maquettage  sur  la  qualite  du  logiciel  fourni  aux  bancs 
d' integration  est  rendue  difficile  pour  les  deux  raisons  suivantes  : 

-  Le  maquettage  est  I'une  des  composantes  de  la  methode  de  travail,  au  niveau  des  specifications 
fonctionnel les  detailiees  ;  le  resultat  obtenu  est  done  inherent  i  1 'ensemble  de  la  methode, 
rimpact  purement  maquette  etant  quasiment  impossible  S  extraire. 

-  La  nouveaute  des  functions  assurees  par  le  logiciel,  la  nouveaute  de  1 'architecture  et  le 
caractere  d'avion  demonstrateur  font  du  Systeme  Avionique  RAFALE  un  cas  particulier,  rendant 
toute  comparaison  delicate  par  rapport  aux  systemes  precedents. 

Neanmoins,  analyse  faite  par  le  personnel  des  bancs  d' integration,  il  ressort  que  le  nombre 
de  fiches  d'evolution  liees  aux  erreurs  du  niveau  specification  est  en  nette  regression  par 
rapport  i  son  niveau  habituel  ;  relativement  A  1 'ensemble  des  fiches  d’evolution,  sa  part  a  ete 
reduite  environ  de  moitie. 

8  -  CONCLUSIONS  ET  ENSEIGNEHENTS  DU  MAQUETTAGE  PE  SPECIFICATIONS  FONCTIONHELLES  DETAILIEES 
8.1  -  Ce  que  le  .maquettage  permet 

a )  ^e  1  iora  t  i  _in_des_S2€c  i  f  i  c  a  t  i  ons 
Controle  de  forme 


La  relecture  critique  permet  de  corriger  et  de  completer  la  specification  pour  I'amener  i 
un  niveau  de  qualite  autorisant  son  codaqe  direct  par  des  informaticiens  (equivalent  manuel  des 
futures  specifications  formellcs  ou  i'outil  se  charge  3i  Ta  i^ecture  et  permet  une 
compilation) . 

Le  maquettage  agit  i  ce  niveau  cowne  un  puissant  reveiateur  d'erreurs  et  un  contrfile 
qualite  efficace. 
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Contrdle  de  fond 


L'outll  maquette  permet  une  r6el1e  validation  fonctionnelle  de  1a  specification  au  niveau 
module,  eouipement  ou  systeme  validation  horizontale  (tests  exhaustifs  d'un  module)  ou 
verticale  (test  d'une  chalne  fonctlonnelle  donnee). 

b)  £ourn1ture_de  J.eux_de  test_ou  d'eien«nts_de  recette 

Les  tests  realises  sur  1a  maquette  (comblnaisons  d'entrees  et  sorties  correspondantes)  ont 
servi  S  fournir  des  Jeux  d'essais  aux  cooperants. 

Ces  Jeux  d'essais  ont  ete  utilises  experimental ement  dans  1e  cadre  du  RAFALE  conme  aide  & 
la  mise  au  point  chez  les  cooperants. 

En  effet,  la  maquette  etant  representative  de  rarchitecture  du  systeme  reel,  elle  permet 
de  generer  les  informations  de  simulation  ou  de  stimulation  au  niveau  souhaitl. 

D'oO  la  possibilite  d'organiser,  en  amont  de  retape  dMntegration  une  recette 
fonctlonnelle  partielle  des  equipewents. 

c)  Oisposj^Mon  d'une  rtf^^ence  fonctlonneUe  conrode 

Une  fois  validee,  la  maquette  est  entretenue  de  toutes  les  modifications  apportees  au 
systeme  et  reste  done  la  reference.  11  est  alors  possible  de  I'utiliser  (sous  reserve  d'une 
ergonofflie  suffisante)  comae  une  "documentation  vlvante"  et  representative  du  systeme,  portable 
et  ne  necessitant  pas  de  materiel  specif loue  :  ce*"^  des  fins  pedagogiques ,  d1dactTques~~ou 
trivlalement  pour  analyse  et  contrdle  de  cas  de  fonctlonnement  non  nominaux  du  systeme. 

d )  V 1  s  1  b n  1 1 e_au  n  1  veau_e vo l^u 1 1  on/ recuperat i^on 

La  quallte  des  specifications  autorise  1 'analyse  et  1e  choix  des  evolutions,  directement 
en  terme  de  solution,  permettant  alnsi  une  connalssance  a  priori  de  leur  fmpact  sur  le  logiciel. 
La  maquette  elle^meme  peut  servir  de  banc  d'essai  pour  tester  fonctlonnel lement  les  dites 
evolutions  et  s'assurer  de  leur  adequation  aux  besolns  avant  leur  mise  en  chantier.  Enfin,  la 
corresponda.cc  document  de  specification/module  de  logiciel  permet  de  prevoir  et  de  planifler  la 
recuperation  de  logiciel.  Elle  permet  en  outre,  apres  analyse,  de  disposer  de  gabarits  en 
matiere  de  volume  de  logiciel,  de  charge  calcul,...  ou  meme  cout. 

La  consequence  directe  du  maquettage  est  de  disposer  de  specifications  autonomes  et 
auto-suffisantes  pour  reallser  et  tester  le  logiciel,  module  par  module  ou  equipement  par 
equipement. 

Pour  des  systemes  tres  decentralises  de  type  RAFALE,  ceci  permet  de  fournir  i  chacun  des 
intervenants  les  elements  precis,  necessaires  et  suffisants  4  la  tAche  qu'il  doit  conduire.  Ce 
point,  qui  concourt  4  la  simplicite  et  4  la  clarte  des  documents,  permet  egalement  une  bonne 
protection  des  informations  confidentletles. 

f)  Ameij^oration^de  la^quaii  te^du  £Fodu1t  final^ 

Outre  le  gain  de  qualite  obtenu  pour  I'etape  de  specification  fonctlonnelle  detail  lee, 
I'exploitation  de  la  maquette,  particulierement  rutilisation  des  tests  automatiques,  permet  et 
a  permis  d'aroeiiorer  la  conflance  dans  le  prodult  final.  En  effet  des  centaines  de  tests  ont  ete 
realises  relativement  4  des  configurations  avion  non  nominales,  permettant  ainsi  de  decouvrir 
(et  de  remedier)  4  des  situations  non  prevues  a  priori  dans  la  specification.  De  meme  la 
recherche  d'un  profil  de  pannes  donne,  par  balayage  combinatoire  systematique  de  toutes  les 
entrees  a  permis  de  conforter  les  analyses  de  panne  et  les  solutions  choisies. 

-  Ce  que  le  maquettage  impligue 

a)  Une  flesti^on  rijoureuse^et  out121ie_<ies_interfaces  il§000_dans  le_cas_du  RAFALE 

La  collection  des  interfaces  entre  modules  et  entre  equipements  represente  le  coeur  de  la 
"machine"  ;  e'est  4  partir  de  ces  donnees  que  vont  etre  creees  automatiquement  les  variables 
logicielles  de  la  maquette,  lesquelles  pourront  etre  stimuiees  et  scrutees  en  phase  de 
val iddtion, 

II  faut  done  disposer,  avant  de  commencer  le  maquettage,  d'une  description  complete  et 
coherente  de  ces  interfaces,  ce  qui  demande,  outre  une  extreme  riqueur,  un  gros  travail  de 
synthese  et  de  rapprochement. 

b)  Une  lescri£ti.on  £recise  et_com£iete  des  fonctions  de_transfert 

Pour  les  modules  que  I'on  desire  valider,  la  realisation  du  logiciel  maquette 
correspondent  consiste  4  decrire  par  du  code  executable  (manuel lement  dans  le  cadre  du  RAFALE) 
les  fonctions  de  transfer!  extraites  du  docimtent  de  specification.  II  est  done  indispensable  que 
cette  description  solt  suffisamment  fine  pour  pouvoir  exprimer  chaque  sortie  du  moduW  selon  une 
combinaison  mathematique  des  entrees  ;  dans  le  cas  oO  la  description  est  trop  generale,  11  y  a 
valeur  ajoutee  entre  la  specification  et  la  maquette,  ce  qui  est  contraire  au  prIncipe  de 
validation  des  specifications. 
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c)  Une  documentation  et_de  ia_confi2^uration 

L'abondance  et  la  var16t6  de  la  documentation,  1a  n6cessit6  de  sa  remise  a  jour 
systdmatique  (toute  Evolution  ne  peut  ^tre  d^crite  <iue  par  modification  coh^rente  et  immediate 
de  la  documentation  concern6e),  exigent  un  support  de  documentation  souple  et  efficace. 

De  m^,  le  parall^lisme  Indispensable  entre  les  6tats  de  definition  : 

•  documentation  (d  tous  niveaux) 

-  logiciel  maquette 

-  logiciel  reel 

implique  une  gestion  de  configuration  rigoureuse  et  connode. 

8.3  -  Conclusion 


Pour  synthetiser  le  bilan  de  1 'experience  ainsi  acquise,  1e  mieux  est  de  rappeler  que 
1 'avion  RAFALE  a  effectue  son  premier  vol  le  4  Juillet  1986,  avec  six  mois  d’avance  sur  I'objectif 
fixe  par  TEtat,  et  que  les  90  vols  effectues  en  six  mois  et  revaluation  conduite  par  le  Centre 
d'Essais  en  Vol,  I'Annee  de  I'Air  et  la  Marine  Nationale  Francaise  ont  conclu  8  I'excellente 
adaptation  de  1 'avion  et  de  son  systeme  aux  objectifs  operationnel s  qui  lui  avaient  ete  fixes. 

Les  principes  exposes  dans  cette  note  seront  done  poursuivis  en  vue  d'une  application  dans 
les  prograames  futurs,  et  d'une  integration  dans  1 'effort  methodologique  et  de  developpement 
d'outils  mene  par  les  Avions  Marcel  Dassault  et  de  facon  plus  generale  par  I'industrie 
aeronautique  francaise. 


DISCUSSION 


E.Cambise,  IT 

( 1 )  What  is  the  size  of  the  embedded  software  of  the  RAFALE? 

(2)  What  is  the  ratio  between  the  development  effort  of  the  prototype  software  and  that  of  the  “target”  embedded 
software? 

Author's  Reply 

( 1 )  The  size  of  ihe  operational  software,  the  specifications  of  which  were  submitted  for  prototyping,  is  of  the  order  of 
200  koctets.  (This  software  does  not  include  flight  command  software.)  The  effort  authorized  for  the  functional 
specification  stage  for  purely  prototyping  activities  represents  42  man-months. 

(2)  I  cannot  put  a  number  on  the  relationship  between  the  effort  of  developing  prototyping  software  and  of  dcveu>ping 
operational  software,  because  the  real  software  was  developed  from  specificati(>ns  in  different  machinery  by 
different  companies.  From  all  accounts,  this  ratio  is  well  below  one. 


G.Bouche,  G£ 

( 1 )  What  are  the  key  differences  between  the  prototype  software  and  the  operational  (embedded)  software  that  make 
it  so  much  easier  and  fastei  to  write  the  prototype  software,  although  it  will  be  fully  functional? 

(2)  What  is  the  approximate  difference  in  man-years  between  the  prototype  software  and  the  embedded  software  in 
RAFALE? 

Author's  Reply 

( 1 )  The  prototype  software  was  developed  very  rapidly  on  nonspecific  materials  and  under  different  constraints  from 
the  operational  software  —  functional  reliability,  efficacy,  language,  respect  of  real  lime,  etc.  —  remaining 
functionally  identical  nonetheless  (from  the  close  temporal  aspect).  Only  the  test  trials  resulting  from  the  prototype 
are  compatible  after  formatting  of  real  interfaces. 

(2)  See  answer  to  the  question  posed  by  Mr  E.Cambise. 
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Abstract 


Existing  avionics  systems  are  designed  as  a  set  of  subsystems  integrated  by  command  and  control  software  m  a  centr?)  processor 
system.  In  future  avionics  systems,  the  complexity  of  ’his  critical  so^iwarc  is  expected  to  mcrease  dramatically,  leading  lo 
potentially  explosive  growth  in  both  software  costs  and  the  likelihood  of  critical  ;>oftware  errors.  As  the  software  increases  in 
both  its  complexity  and  its  criticality  to  the  success  of  the  overall  mission,  (c.g..  by  the  infusion  of  Al.  image  processing, 
distributed  processing,  etc.)  the  vulnerability  of  the  system  to  software  enors  also  increases  dramatically. 


This  problem  can.  and.  we  feel,  must,  be  alleviated  by  the  use  of  new  methods  for  defining  the  system  architecture,  and  allowing 
the  software  architecture  to  constrain  the  design  space  of  the  hardware  physical  architecture.  Thus,  the  process  of  developing 
the  software  architecture  must  change  both  in  Us  developmcm  methods,  and  the  avionics  system  design  cycle  stage  at  which  it  is 
performed.  It  is  thus  cntical  for  the  software  arc'  itecture  to  be  a  dnver  of  the  system  architecture  design  decisions. 


In  this  paper,  we  consider  the  technology  developments  which  have  led  us  to  this  problem  and  their  impact  on  the  functionality 
and  design  of  new  systems.  Following  this,  we  discuss  the  current  sequence  for  performing  the  physical  and  software 
architectural  design,  including  a  defmition  of  the  software  architeaore.  with  examples.  FrAm  this,  we  discuss  what  we  feel  arc 
the  likely  consequences  of  using  these  methods  for  designing  such  new*  avionics  systems,  and  one  potential  solution  to  these 
problems. 


1.0  Introduction 


h  will  come  as  no  surprise  to  practitioners  in  avionics  systems  that  the  characteristics  of  such  systems  have  undergone  a  rapid 
evolution  in  the  last  I0-I5  years,  and  that  a  similar,  if  not  greater  rate  of  change  is  ahead  in  about  the  same  time  interval  The 
nature  of  these  changes  may  be  characterized  using  ..  vancty  of  metrics,  some  of  which  are  summarized  in  Figure  I.  l-or  those 
characteristics  which  can  be  numerically  evaluated,  the  growth  is  described  by  a  geometrical  progression,  not  b>  a  linear 
progression.  During  this  period,  the  sequence  of  steps  by  which  an  avionics  system  is  designed  has  not  undergone  such  a  rapid 
change;  a  question  which  we  would  like  to  address  is.  "will  our  current  system  design  methods  be  adequate  for  the  tvpes  of  future 
systems  characterized  by  these  metrics?' 
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Figure  I 

In  the  past,  avionics  systems  were  simple  by  modem  standards,  with  architecturally  small,  single  computers  with  processing 
limited  to  conceptually  simple  algorithms  such  as  vector  rotations,  ballistics  computations,  display  scaling,  manual  operator 
interfaces,  and  with  overall  functionality  constrained  primarily  by  the  amount  of  hardware  supportable  by  the  platform  in  terms 
of  weight,  power,  and  volume.  In  current  modern  systems,  the  avionics  system  supports  man-in-the-loop  operator  mterfaccs. 
requiring  more  powerful  and  larger  processors  capable  of  command  and  control  processing  in  conjunction  with  the  human 
decision  maker.  Such  system  designs  arc  constrained  both  by  the  hardware,  as  previously,  and  the  software  which  must  be  able 
to  use  the  constrained  hardware  to  provide  the  required  functionality.  In  future  systems,  characterized  by  automated  (with 
manual  override)  control  with  its  inherent  need  for  increased  fault  tolerance.  Al.  sensor  fusion  functions,  and  rather  powerful 
computers,  the  prima^  system  design  constraint  will  be  the  software  (i.e..  the  set  of  algorithms  and  data  structures  required  to 
fulfill  the  system  specifications). 


These  future  systems  will  require  changes  to  the  methods  b>-  which  the  system  design  is  performed;  the  geometrical  changes  m 
the  system  complexity  leading  to  greater  numbers  of  much  more  powerful  processors  will  not  allow  us  to  continue  designing 
systems  in  the  same  ways  as  before. 


The  process  of  designing  an  avionics  system  may  be  described  as  a  sequence  of  design  stages  or  steps.  Although  the  number  ol 
steps  and  their  exact  nature  is  highly  vanable.  for  the  purposes  of  this  paper  we  identify  four  top-level  steps  in  Figure  2 


This  sequence  is>  of  course,  predicated  on  the  assumption  that  these  stages  may  be  sequennalh  performed,  i  e.,  that  the 
information  needed  to  initiate  each  stage  ongmates  only  with  the  preceding  stages  For  past  and  current  systems,  this 
assumption  is  justified,  but  ii  is  the  premise  of  this  paper  that  this  assumption  may  pot  be  warranted  m  highly  complex  systems 
such  as  some  of  those  current!’  on  the  drawing  board,  particularly  for  the  last  two  steps  listed  in  Figure  2  It  is  not  obsious.  in 
sy.siems  with  a  large  number  of  interconnected,  powerful  processors,  that  it  necessanh  will  be  possible  to  design  the  processes 
for  each  processor  without  subsequently  modifying  the  number  of  processors  and  their  interconnections,  thus  signiJicanth 
increasing  the  cost  and  nsk  ci  the  aviomcs  development 

(1)  Conceptual  Design  --  Determining  the  concepts  to  be  used  in  the 
avionics  design.  This  activity  derives  these  concepts  from  the 
system  specification;  for  example,  when  the  system  specification 
calls  for  an  aircraft  to  use  acoustics  for  underwater  detection, 
the  conceptual  design  will  identify  the  type  of  acoustic  devices 
required  (e.g.,  sonobuoys.  dipping  sonor)  and  structures, 
interfaces,  and  controls  required. 

(2)  Functional  Design  --  Given  that  the  set  of  system  concepts 
has  been  defined,  the  actual  functions  to  be  performed  in 
support  of  each  concept  must  be  determined.  An  example  of 
this  would  be  the  decision  to  deploy  sonobuoys  automatically 
in  response  to  passing  a  given  geographical  position. 

(3)  Systems  Architecture  --  Having  determined  a  set  of  functions  to 
be  provided,  the  systems  architecture  can  be  defined.  Examples 
of  systems  architecture  decisions  are  the  devices  required  to 
handle  a  sonobuoy  system,  the  nature  of  their  interconnection , 
and  the  specific  operator  actions  which  are  needed  to  manage 
these  devices.  Included  in  the  current  systems  architecture 
phase  are  decisions  about  the  number  and  type  of  processors 
needed  and  the  nature  of  their  interconnections. 

(4)  Software  Architecture  --  Upon  presentation  of  a  system 
architecture,  the  software  architecture  may  be  determined.  This 
activity  consists  of  such  actions  as  designing  the  functions 

to  be  provided  by  each  processor,  determining  the  communications 
protocols  to  be  used,  defining  what,  if  any,  operating  system 
should  be  used  (including  how  the  specific  operating  systems 
constructs  are  to  be  used),  designing  the  modular  breakout  of 
the  software,  etc. 

Conventional  Avionics  System  Design  Sequence 

Figure  2 

Considering,  for  example,  the  LAMPS  Mark  HI  system,  we  note  that  the  LAMPS  conceptual  development  grew  out  of 
experience  with  previous  LAMPS  systems,  as  well  as  out  of  experience  with  several  relatively  simple  prototypes  constructed  and 
tested  over  several  years.  For  the  full  scale  development,  these  concepts  were  used  to  design  an  avionics  ststem  consi.stmg  of  5 
general  purpose  computers,  using  a  variety  of  interfaces  (point-to-point  channel  atiachmenis.  data  link,  and  a  communicaiic  .is 
bus).  The  software  irchitecture  was  then  determined  independently  for  each  of  these  computers,  along  with  the  communjcaiic'ns 
protocols  needed  to  fulfill  these  requirements.  For  the  sysienLioftware  architecture  steps,  this  assumption  of  independence  was 
valid  for  two  principal  reasons: 

•The  LAMPS  problem,  in  spite  of  the  presence  of  a  large  number  of  functions,  was  very  simple  struciurallx 

•Because  of  LAMPS'  inherent  structural  sunpbeity.  a  federated  distribution  of  functions  among  the  various  processing 
elements  provided  a  saiisfactorv  solution  to  the  software  architecture  (i.e..  a  federated  disinbuuon  is  one  m  which  ih'’ 
allocation  of  functions  among  processing  elements  is  physically  fixed  because  of  asymmetrical  processing  capability  and 
interfaces}.  A  by-product  of  such  a  federated  Ainctioi.al  distribution  is  that  the  choice  of  commumcation.s  protocols  for 
each  communication  path  is  independent  of  any  other  communication  paths. 

It  IS  clear  that  the  avionics  systems  of  the  future,  moving  in  the  directions  of  increasing  function  exemplified  by  ATF  and  I.HX 
and  illustrated  in  Figure  1,  are  at  least  an  order  of  magnitude  more  complex,  requiring  more  fully  integrated  functions  From  the 
point  ‘»r  view  from  which  this  papei  -s  being  wnltcn.  the  key  diflTcrencc  between  current  systems  such  as  L.AVPS  and  such  future 
svstems  lies  in  the  oegree  of  interconnection  among  the  various  subsystems.  For  example,  in  LAMPS,  the  sensor  subsystems, 
such  as  the  acoustics,  have  no  du-ect  interface  with  the  navigation  subsystem  other  than  through  a  cornmon  data  base.  On  the 
other  hand,  lor  systems  such  as  ATF,  virtually  all  functions  are  envisioned  to  be  fully  integrated;  e.g..  the  FLIR  system  images 
can  be  processed  both  f-  r  targeting  information  to  be  coupled  to  weapons  delivery,  and  for  navigation  fixing.  Beyond  such 
direct  interfaces,  the  FL  R  video  must  be  digitally  enhanced  for  pilot  presentation,  involving  both  extensive  hardware  and 
software  interfaces. 


It  is  important  ;o  note  also  that  the  sequence  of  decisions  m  the  design  process  is  influenced  by  the  factors  which  drive  the 
design.  In  the  past,  hardware  physical  charatiensiics  such  as  weight,  powen  and  size,  as  well  as  performance,  were  prime  uciors 
m  determining  the  physical  design;  thus  makuig  the  hardware  choices  first,  followed  by  the  softw’arc  architecture  wuhin  the 
physical  constraints  made  sense.  It  is  the  premise  of  this  paper  that  the  current  avionics  system  design  mcthodologx  applied  to 


iuiure  corrokx  !fysiems  lead  lo  expensive  (cost  and  schedule)  development  iterations  and  subopiunal  implementations  Now. 
in  the  face  of  the  increased  system  complexity  required,  the  difTiculty  m  succcssfullv  integrating  the  required  software  functions  m 
these  systems  forces  the  software  architecture  to  dnvc  the  overall  physical  design  although  physical  aliiibuies  such  as  weight  and 
power  will,  of  necessity,  constrain  the  resulting  design. 


In  the  remainder  of  this  paper,  we  discuss  the  relationship  between  the  s\'sicm  architecture  and  software  architecture  m  Section 
2.0.  a  new  approach  to  a  coordinated  system,  software  architecture  in  Section  3.0.  and  identify  the  key  conclusions  in  Section  4.0 


2.0  System  Architecture  vs.  Software  Architecture 


The  process  of  defining  an  architecture  consists  of  defining  a  structure  and  the  relationships  between  the  entities  which  make  up 
the  structure.  This  definition  of  architecture  applies  to  many  fields;  for  cxai^lc.  m  construction,  the  architecture  consists  of 
defining  the  relationship  between  shapes,  colors,  textures,  and  functions.  Similarly,  in  avionics  systems,  the  process  of  defining 
the  avionics  architecture  (i.e..  the  system  architecture)  consists  of  defining  the  relationships  between  entities  such  as  sensors, 
actuators,  and  weapon  systems  and  the  human(s)  who  will  operate  and  use  the  system. 


For  discussion,  we  choose  to  separate  the  concept  of  the  avionics  system  architecture  into  the  physical  architecture  and  the 
software  architecture.  The  physical  architecture  consists  of  the  structures  and  relationships  among  the  physical  elements  of  the 
system,  e.g..  the  processors,  peripherals,  busses,  sensors,  and  aauators.  The  software  arctuiecture.  on  the  other  hand,  consists  of 
the  assignment  of  the  control  functions  which  actually  perform  the  coordination  of  the  system  entities  into  computational 
elements,  and  the  relationships  between  the  computational  elements  and  the  data  structures.  In  the  software  architecture,  the 
objects  consist  of  two  major  categories;  1)  the  processes  which  perform  the  functions  required  of  each  computational  element, 
and  2)  the  data  structures  containing  the  information  to  be  processed  by  each  of  these  processes.  To  this  point,  the  software 
architecture  can  be  thought  of  as  if  we  were  targetmg  to  a  uniprocessor.  The  software  architecture  also  then  mcludes  the 
partitioning  of  these  processes  and  data  structures  into  a  set  of  physical  processors.  Thus,  the  software  architecture  is  developed 
In  conjunction  with  the  system  architecture  to  define  the  number  and  type  of  the  processors,  but  the  software  architecture  alone 
determines  the  placement  of  the  process  functions  among  the  processors. 


In  current  systems,  the  software  architecture  could  successfully  be  performed  sequentially  following  the  system  architecture 
because  there  are  only  a  small  number  and  type  of  processing  elements,  and  the  function  of  each  process  was  very  closely 
coruicaed  with  the  system  architectural  elements  themselves.  T^us.  for  example,  in  the  LAMPS  helicopter,  we  fmd  the  primary 
command  and  control  computer  to  be  a  single  entity,  with  no  backup,  coordinating  with  a  set  of  peripherals  and  processors, 
which  were,  in  general,  not  general  purpose  computers.  Specifically  in  the  LAMPS  helicopter  the  other  principal  processors 
consist  of  a  sensor  processor  for  performing  acoustic  analysis,  and  an  ES.M  processor  for  analysing  incoming  electromagnetic 
radiation.  The  functions  performed  by  these  processors  is  specific  to  these  subsystems,  and  no  functional  backups  on  the  aircraft 
were  felt  to  be  requued  (or  feasible  at  that  time)  across  the  system  boundaries.  Thus,  the  allocation  of  funciion  wiihin  the 
LAMPS  helicopter  to  the  various  processors  was  dictated  by  the  choice  of  sensors  themselves. 


In  modem  avionics  systems,  on  the  other  hand,  we  find  that  the  processing  requirements  are  sufficiently  great  that  it  is  necessary 
to  have  a  number  of  processors  in  each  of  the  avionics  functional  elements.  This  means  that  the  processor-Aincijon  assignment 
ts  both  more  flexible  and  more  complicated,  as  issues  of  communications  protocols,  fault  tolerance,  and  reconfiguration  become 
critical  to  meeting  the  overall  avionics  systems  objectives.  If  decisions  relating  to  the  software  architecture  are  left  until  the 
processors  and  their  interconnection  have  been  defined,  the  design  space  for  the  software  architecture  will  likely  have  been  so 
constrained  that  it  will  not  be  feasible  to  fulfill  the  overall  system  objectives. 


3.0  An  Approach  to  System/Software  Architecture  for  Complex  Systems 


!f  the  generation  of  a  system  architecture  ioUowcd  by  the  software  architecture  seems  not  to  meet  the  needs  of  future  system 
designs,  the  logical  question  to  ask  is  "What  sequence  of  system/softwarc  archileaural  development  will  result  in  both  a 
reasonable  architecture  and  a  working  sysiem  in  a  reasonable  period  of  lime?"  In  Figure  3,  we  show  a  refinement  of  steps  2  and 
4  for  Figure  I  into  7  steps.  These  7  steps  are  contrasted  with  a  new  sequence  of  seven  steps  (shown  in  Figure  4)  to  address  the 
projected  highly  complex  environment  of  the  future. 


In  order  lo  evaluate  these  seven  steps  and  their  use  in  constructing  a  real-time  aviorucs  sysiem,  let  us  begin  by  considering  the 
steps  as  they  are  now  generally  performed  (see  Figure  3).  It  will  be  observed  that  there  are  some  fundLamenia!  dissimilarities 
between  the  sets  of  steps  in  Figures  3  and  4.  In  the  proposed  approach  we  arc  considering,  we  find  that  by  the  time  step  (3)  is 
completed,  the  high  level  algorithms  and  data  structures  are  already  in  place  that  are  requu^ed  for  the  overall  system  solution. 
We  note  that  these  are  not  the  low'  level  algorithms  (sometimes  called  "math  flows"  in  the  past)  w’hich  describe  the  processing  on 
behalf  of  individual  sensors  or  actuators.  For  example,  we  would  not  expect  to  fmd  here  the  details  of  the  navigation  equations 
used  to  generate  current  position  from  an  inertial  navigation  system,  but  we  would  expect  to  find  the  flow  of  information  from 
the  navigation  system  to  the  low-light  level  TV  or  the  radar.  ECM  equipment,  etc.  The  key  here  is  that  we  have  defined  the 
algorithms  and  data  structures  based  only  on  the  sensors  and  actuators  in  use.  as  well  as  the  human  interfaces  required,  without 
having  yet  considered  the  information  processing  or  communications  structure.  In  other  w’ords,  we  consider  the  processor  and 
communications  structure  decisions  to  be  a  result  of,  not  the  determiner  of.  the  software  architecture,  from  the  top  level 
perspective. 


Therefore,  by  the  time  we  have  completed  step  (4>,  and  prior  to  defining  the  processor  and  communications  structure,  we  have 
determined  the  complete  functionality  at  the  system  level,  and  have  defined  the  flow'  of  infotroation  that  must  occur  between  all 
of  the  pieces  of  equipment  that  actually  interface  with  the  operational  environment.  By  contrast,  we  note  that  this  is  not 
accomplished  until  after  the  definition  of  the  data  processing  equipment  and  communications  equipment  in  the  conventional 
avjomcs  system  softw-are  engineering  -ichiiccturc  procedures. 
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(1)  w«fine  each  of  Utc  sensors  and  actuators  (including  weapon 
systens)  for  the  systeai,  based  on  the  top  level  system 
requirements.  This  process  accounts  for  required  vehicle 
performance,  flight  envelopes,  weight,  etc.,  but  disregards 
information  processing  and  coonunications  requirements. 

(2)  Define  the  human  interface  fxmctions.  This  consists  of  a 
list  of  operator  functions,  both  input  and  output,  including  a 
model  of  the  required  operator  responses  and  estimate  of 
required  operator  precision  and  speed. 

(3)  Define  the  computational  elements  and  communication  structures 
to  be  used  to  control  these  sensors  and  actuators  and  interface 
with  the  human  operators.  Consider  the  fault  tolerance,  fault 
containment,  and  degraded  modes. 

(4)  Define  the  algorithms  and  data  structures  for  each  of  the 
sensors  and  actuators  defined,  constraining  them  to  fit  with 
the  computational  and  communications  equipment. 

(5)  Deduce  the  information  flows  among  each  of  these  components  for 
all  required  system  nodes.  This  includes  the  dat^  structures  to 
be  communicated,  the  rates  at  which  cotvnunications  must  take 
place,  and  the  required  precision  of  each  data  element. 

(6)  Analyse  the  resulting  system  architecture  for  communications  or 
processing  bottlenecks,  pr^ably  using  a  combination  of 
analytical  and  simulation  techniques. 

(7)  Iterate  steps  3.  throu0)  6.  until  the  system  reliability 
requirements  have  been  satisfied. 

Decomposition  of  Conventional  System  Architecture  Development  Sequence 


(1)  Define  each  of  the  sensors  and  actuators  (including  weapon 
systems)  for  the  system,  based  on  the  top  level  system 
requirements.  This  process  accounts  for  required  vehicle 
performance,  flight  envelopes,  weight,  etc.,  but  disregards 
information  processing  and  communications  requirements. 

(2)  Define  the  human  interface  functions.  This  consists  of  a 
list  of  operator  functions,  both  input  and  output,  including  a 
model  of  the  required  operator  responses  and  estimate  of 
required  operator  precision  and  speed. 

(3)  Define  the  algorittuss  (processes)  and  data  structures  for  each  of 
the  coiiq>onents  (e.g.,  sensors  and  actuators)  defined  in  step  1. 
These  algorithms  define  the  interrelationships  between  these 
components,  not  the  computations  performed  internally.  For 
exan^le,  this  might  define  how  information  from  a  navigational 
conq>onent  would  be  used  to  perform  a  flight  maneuver  or  position 
a  weapon,  not  how  accelerations  measured  by  an  inertial 
navigation  system  are  converted  to  velocity  or  position. 


(4)  Deduce  the  information  flow  among  each  of  these  components  for 
all  required  system  modes.  This  includes  the  data  structures  to 
be  communicated,  the  rates  at  which  communications  must  take 
place,  and  the  required  precision  of  each  date  element. 

(5)  Partition  this  information  fi.jw,  considering  requirements  for 
fault  tolerance,  fault  contalranent,  and  degraded  modes 
(including  potential  software  faults  in  addition  to  hardware 
faults)  into  processing  elements  and  supporting  communication 
structures  (e.g.,  busses). 

(6)  Analyse  the  resulting  system  architecture  for  communications  or 
processing  bottlenecks,  probably  using  a  combination  of 
analytical  and  simulation  techniques. 

(7)  Iterate  steps  5.  and  6.  until  the  system  reliability 
requirements  have  been  satisfied. 


Proposed  System  Architecture  Development  Sequence 


The  big  difTerence  is  that  in  the  event  of  difficulty  meeting  any  of  the  data  processing  constraints,  such  as  fault  tolerance,  fault 
containment,  and  degraded  modes,  in  the  normal  procedures  the  entire  data  processing  structure  and  commurucations  structure 
may  have  to  to  be  modified  in  several  design  iterations.  This  cannot,  of  course,  be  done  until  each  problem  has  been  diagnosed, 
which  may  frequently  not  occur  until  after  the  system  has  neen  developed  and  partially  implemented. 

This  nsk  of  needing  major  design  iterations  is  a  critical  failing  of  such  a  system  since  it  leads  to  high  cost  and  or  poor  quabtt. 
and  wc  believe  that  the  risk  can  be  contained  with  our  new  approach.  This  belief  is  supported  by  the  now  well-documented  fact 
that  the  early  detection  of  enors  in  a  system  irr^lementation  dramaticaUy  reduces  the  cost  to  correct  them.  We  note  that  the 
iterative  pan  of  the  proposed  approach  affeas  only  the  last  two  steps,  steps  (S)  and  <6);  rather  than  aifecting  the  whole  design, 
as  in  the  conventional  approach. 


As  an  example  of  a  design  problem  which  can  be  avoided  by  this  approach,  there  are  a  number  of  cases  in  which  a  set  of 
interconnected  computers  has  been  configured  to  provide  a  hi^  degree  of  fault  tolerance  by  incorporating  suitable  redundanc> 
It  is  frequently  the  case,  however,  that  when  the  software  is  being  d<*cigned.  the  required  functions  could  not  be  implemented 
without  additional  hardware  support  because  the  underlying  algonthms  and  data  struaures  had  not  been  designed  and 
considered  prior  to  defining  the  interconnecuon  structure. 


It  might  be  argued  mat  the  current  approach  (see  Figure  3)  allows  the  detailed  hardware  design  to  begin  earlier  m  the  system 
design  cycle.  1  his  is  true,  and  in  die  past,  an  early  start  on  the  hardware  design  was  considered  critical  to  meetmg  overall  system 
schedules.  However,  the  new  (correct)  emphasis  is  on  the  use  of  off-the-  shelf  hardware  elements,  reduang  the  need  for  allowing 
for  long  lead  times  for  hardware  design,  and  the  increased  software  complexity  has  caused  it  to  increasingly  dominate  both  the 
system  cost  and  schedule. 


From  the  point  of  view  of  the  skills  to  be  used  for  developing  a  system  under  this  paradigm,  there  is  another  fundamental 
difference  between  these  approaches.  In  steps  (3)  and  (4).  at  the  very  beginning  of  the  high  level  system  design,  the  software 
engineer  must  be  already  involved.  The  skills  needed  for  this  step  consist  of  a  knowledge  of  the  data  processing  and 
communications  issues  of  the  avionics  system,  rather  than  the  systems  issues  which  were  needed  in  steps  (I)  and  (2).  and  which 
will  be  needed  in  steps  (5)  and  (6).  To  an  increased  extent,  system  design  decisions  will  be  determined  by  software 
considerations.  While  it  is  possible  that  a  few  individuals  have  the  requisite  education  and  expenence  to  perform  all  of  these 
steps,  the  normal  case  is  that  personnel  with  knowledge  of  such  things  as  the  flight  dynamics,  mission  profiles,  and  operator 
interface  will  not  be  able  to  optimally  define  the  information  processing  and  communications  design.  Thus,  this  approach 
encourages  the  use  of  system  architecture  teams  with  greater  software  skills  and  awareness  to  define  the  high  level  design 


4.0  Conclusions 


The  current  sequential  nature  of  the  system  engineering,  determining  a  physical  architecture  followed  by  performing  the  software 
engineering  to  produce  the  new.  extremely  complex  avionics  systems  makes  the  design  process  prone  to  sub-optima)  solutions  or 
unworkable  designs  leading  to  critical  functional  errors.  These  errors  arc  not  so  much  the  traditional  types  of  enors  exemplified 
by  targeting  errors  or  incorrect  displays,  but  are  likely  to  be  some  of  the  more  subtle  problems  such  as  failure  to  meet  timing 
requirements  (appearing  usually  as  'iniermittent”  errors),  or.  worse  yet.  failure  to  respond  properly  lo  component  failure  with  an 
appTOpnate  reconfiguration  or  degraded  mode. 


Wc  have  described  a  proposed  new  sequence  for  performing  such  a  major  aviomcs  system  design  by  intermixing  the 
system/software  engineering  tasks  to  isolate  the  complexity  introduced  at  each  step,  and  minimizing  the  number  of  factors  which 
must  be  considered  in  the  iterative  pan  of  the  design  process.  This  should  result  both  m  a  less  error-prone  high-level  design,  and 
in  a  process  with  a  much  greater  likelihood  of  success  at  a  more  controllable  cost.  IBM  is  strongly  committed  to  the  production 
of  such  systems,  and  is  cuncntly  carefully  considering  approaches  such  as  the  one  presented  in  this  paper  to  ensure  that  the 
complex  avionics  systems  needed  for  the  future  can  be  as  successful  as  those  produced  to  date. 
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A  COMPARISON  OF  INTEGRATED  AND  SEPARATE  SYSTEMS 
FOR  FUGHT  CONTROL  AND  NAVIGATION 


by 

HBuitkamp 

LITEF  (Uttoo  Technische  Wcrlc^  der  Hellige  GmbH 
Lbrracher  StraM 
D  7800  Freiburg 
Germany 


1  .  Summary 

Modern  aircraft  use  algnals  from  gyros  and  accelerometers  In  various  subsystems,  among 
these  flight  control,  a t t I t ude/ hea dl ng  and  navigation  systems.  utilisation  of  the  same 
set  of  Instruments  for  these  three  functions  could  be  envisaged. 

This  Investigation  discusses  some  possible  steps  leading  to  an  Integration  of  navigation 
and  flight  control  functions  Into  one  system.  Obvious  advantages  of  such  a  system  could 
be  a  decrease  in  weight,  power  consumption  and  volume. 

Emphasis  of  this  paper  Is  laid  on  technical  feasibility  and  on  possible  development 
risks  associated  with  the  application  Involving  inherently  unstable  alrcraft- 
The  main  requirements  for  reliability,  accuracy,  and  bandwidth  of  the  sensor  data  differ 
according  to  whether  the  application  is  for  navigation  or  for  flight  control.  A  study  of 
these  requirements  forms  a  reasonable  basis  for  the  concept  of  an  integrated  system. 

The  conclusion  is  that  an  integrated  system  is  appropriate  for  an  inherently  stable  air¬ 
craft,  but  that  a  lot  of  risks  are  Involved  in  the  development  for  control  configured 
vehicles. 

Investigations  have  shown  that  the  essential  reduction  in  weight,  power,  and  volume  for 
systems  combining  navigation  and  flight  control  tasks  is  very  difficult  to  achieve. 
Consequently,  f i rst -i ntegratt on-stage  systems,  which  include  only  the  flight  control 
sensors  and  the  at t l t ude/ heading  determination,  are  recommended.  Such  systems  are 
already  produced  at  LITEF  and  are  an  integral  part  of  the  EAP^  which  Involves  an 
Inherently  unstable  aircraft.  During  the  first  flight  trials  In  August  1986  the  system 
successfully  demonstrated  its  capabilities. 


2.  introduction 


Modern  fighter  aircraft  require  an  appropriate  FCS^  to  provide  sufficient  handling  qual¬ 
ity  and  adequate  stability  In  order  to  reduce  the  pilot's  workload  and  simultaneously 
provide  a  stable  weapon  delivery  platform.  In  addition  an  autonomous  navigation  system 
and  an  AHRS^  are  required  in  most  aircraft  applications. 

ii 

To  date  the  inertial  data  required  by  the  Individual  functions  -  FCS,  AHRS  and  litj 
has  been  provided  by  Independent  sets  of  gyros  and  accelerometers.  The  redundancy  of  the 
sensors  Increases  the  weight,  size  and  cost  of  the  whole  aircraft.  Furthermore  an 

increase  In  the  number  of  sensors  introduces  extra  maintenance  problems.  Therefore  the 
utilisation  of  the  same  sensors  for  flight  control  purposes,  for  attitude  and  heading 
determination  and  for  navigation  purposes  could  be  envisaged.  An  integrated  system  has 
to  deliver  the  Inertial  sensor  data  with  at  least  the  same  accuracy,  functional  relia¬ 
bility  and  lower  life  cycle  costs  as  that  of  a  separate  system. 

Using  strap  down  technology,  integrated  systems  for  flight  control,  at 1 1 tude / head  I ng 
determination  and  navigation  purposes  have  been  successfully  Implemented  In  the  trans¬ 
port  aircraft  field.  This  goal  also  seems  to  be  achievable  In  the  very  near  future  for 
agile  Inherently  unstable  fighter  aircraft,  but  there  Is  a  great  deal  of  work  required. 

A  brief  summary  of  recent  development  efforts  in  this  field  forms  a  basis  for  our  own 
investigations . 


Experimental  Aircraft  Program 
^  Flight  Control  System 

^  Attitude  and  Heading  Reference  System 
**  Inertial  Navigation  System 
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2.1.  History 

One  of  the  first  Integrated  systeass  was  built  at  Litton  In  1  976  .  It  contains  four 
DTG's^  and  eight  acceleroaeters  In  a  pyraoidal  axes  configuration.  It  consists  of  four 
boxes  and  has  a  weight  of  27.7  kg.  The  systen  Is  not  applicable  for  flight  control  and 
navigation  of  a  highly  agile  CCV^  fighter  aircraft  due  to  the  time  delays,  the  measure- 
fflent  ranges  and  the  navigation  accuracy. 

Another  Important  milestone  In  the  development  of  an  Integrated  system  was  the  MFCRS^ 
program,  which  was  started  in  1980  by  the  USAF  together  with  McDonnell  Douglas.  The 
major  components  used  are  two  skewed  mounted  inertial  navigation  systems  H  t»2i  manufac¬ 
tured  by  Honeywell  and  Installed  in  a  F-15  Eagle.  The  Idea  behind  the  skewed  mounting  of 
the  two  orthogonal  strap  down  systems  was  to  provide  sufficient  redundancy  for  flight 
safety  critical  Information  by  using  two  accurate,  costly  and  heavy  inertial  systems 
only.  It  was  discovered  that  the  location  of  the  two  boxes  In  the  aircraft  and  the 
noise  of  the  compensated  sensor  data  have  a  strong  influence  on  the  FCS.  This  affects 
the  handling  quality  of  the  aircraft  although  the  navigation  accuracies  are  hardly 
reduced,  it  became  further  apparent  that  the  latency  of  flight  safety  crltlral  data  pro¬ 
vided  by  the  inertial  systems  allows  only  flying  of  the  aircraft  under  conditions  where 
dynamics  are  not  critical.  Further  investigation  should  be  carried  out  in  order  to 
determine  If  the  navigation  system,  with  only  a  few  modifications,  could  be  used  for 
f 1  Ight  control , 

In  1983  Litton  began  development  of  the  IISA®.  The  system  consists  mainly  of  two  simi¬ 
lar  boxes,  each  with  three  RLC* s^  (28  cm)  and  three  accelerometers.  The  boxes  are  to  be 
Installed  back  to  back  In  the  aircraft,  thus  forming  a  hexagonal  sensor  configuration. 
There  arose,  during  the  development  of  IISA,  several  questions  and  solutions  associated 
with  a  common  sensor  block  for  flight  control  and  navigation.  An  Indication  has  also 
been  attained  as  to  the  necessary  power  consumption,  weight,  volume  and  cost  of  an 
Integrated  system  as  compared  to  the  solution  using  Individually  designed  systems  for 
each  application.  The  first  flight  tests  are  planned  for  1987. 

The  IISA  has  been  conceived  for  inherently  stable  aircraft.  If  used  for  Inherently 
unstable  aircraft,  it  would  be  necessary  to  reduce  the  time  delay  and  increase  the 
bandwidth  of  the  flight  safety  critical  control  data.  To  build  such  a  system,  using 
state  of  the  art  techniques,  would  involve  considerable  development  effort  along  with 
the  associated  risk  and  cost. 


3>  Requirements  for  Inertial  Systems 

The  choice  of  sensors  In  Inertial  systems  combining  the  multiple  functions  of  FCS,  AHRS 
and  INS  into  one  integrated  system,  is  dictated  by  the  function  having  the  highest 
requirements.  In  general  all  sensors  should  have  a  high  accuracy,  integrity  and  a  long 
I  Ife  span . 

The  requirements  imposed  on  the  Inertial  sensors  and  the  safety  critical  data  differ 
depending  upon  whether  they  are  used  for  a  FCS,  an  AHRS  or  an  INS. 

A  table  with  the  most  Important  sensor  data  requirements  Is  shown  below. 


Function 

FCS 

AHRS 

INS 

Bandwidth 

>  50  Hz 

20  Hz 

<  20  Hz 

Data  latency 

<  1 0  ms 

not  critical 

not  criticol 

Reliability 

safety  critical 

safety  criticol 

mission  criticol 

Redundancy 

quadruplex 

duplex 

simplex 

Accuracy,  rel 

5000  ppm 

500  ppm 

50  ppm 

1 00  deg/h 

1  deg/h 

0.01  deg/h 

Accuracy,  abs 

1 0  mg 

1  mg 

0. 1  mg 

Table  3-I  Sensor  Data  Requirements 

As  can  be  seen  from  the  table  the  bandwidth  of  the  safety  •:ritlcal  data  for  flight  con¬ 
trol  should  be  greater  than  50  Hz.  This  value  is  calculated  assuming  a  6  Hz  bandwidth 
for  the  aircraft  dynamics  of  a  CCV  and  the  fact  that  the  bandwidth  of  the  flight  control 
data  should  exceed  the  bandwidth  of  the  aircraft  motion  by  a  factor  of  eight.  The 
bandwidths  quoted  for  an  AHRS  and  an  INS  are  only  rough  mean  values  and  actually  vary 
with  different  aircraft. 


Dynamically  Tuned  Gyro 
Control  Configured  Vehicle 

Multifunction  Flight  Control  Reference  System 
Integrated  Inertial  Sensor  Assembly 
Ring  Laser  Gyro 
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Whereas  a  time  delay  for  the  AHRS  and  INS  functions  is  not  critical,  a  time  delay 
greater  than  10  ms  for  flight  control  data  could  cause  a  destabilising  effect  In  the 
aircraft  control  system. 

The  reliability  can  be  categorised  into  "safety  critical"  and  "mission  critical".  The 
former  category  applies  to  flight  control  data,  the  loss  of  which  would  cause  the  air¬ 
craft  to  be  no  longer  controllable.  Under  special  circumstances  the  three  attitude 
angles  could  also  be  safety  critical.  The  loss  of  an  INS  does  not  influence  the  stabil¬ 
ity  of  the  aircraft,  but  loss  of  attitude  Information  make  It  Impossible  to  complete  the 
mission. 

Usually  a  CCV  aircraft  needs  a  quadruple  redundancy  for  the  flight  safety  critical  data. 
The  attitude  angles  are  required  duplex  delivered  by  the  INS  and  by  a  SAHRS^®,  Cost  and 
weight  restrictions  allow  the  use  of  only  one  INS  In  most  fighter  aircraft  applications. 
The  relative  accuracy  of  the  sensor  data  of  an  INS  with  medium  accuracy  should  not 
exceed  50  ppm  including  all  error  compensations.  The  same  requirement  for  an  AHRS  is  10 
times  lower.  It  is  sufficient  that  the  flight  control  data  have  a  rela’-lve  accuracy  of 
0.5  percent.  The  accuracy  in  the  determination  of  angular  rates  and  accelerations 
differ  in  the  three  applications  by  a  factor  of  100  and  10  respectively. 

In  a  nutshell,  the  task  Is  to  integrate  the  diverging  requirements  of  high  bandwidth  and 
highly  reliable  data  without  special  emphasis  on  accuracy  for  flight  control 

and 

highly  accurate  data  without  special  emphasis  on  latency,  noise  and  bandwidth  for  navi¬ 
gation. 


>< .  Steps  of  Integration 

There  are  at  least  three  ways  of  solving  the  flight  control,  the  a 1 1 1 tude / he  ad i ng  and 
the  navigation  tasks  for  a  modern  CCV,  bearing  In  mind  that  quadruplex  redundancy  for 
flight  safety  critical  data  and  duplex  redundancy  for  both  a 1 1 1 tude / he  ad  1 ng  and  naviga¬ 
tion  functions  are  required. 


No  Integfotion 


[  FCS 

A«FS 

ms  1 

1 .  Step  of  Integrotion 

tiH 

AilKS 

JNS 

2.  Step  of  Integrotion 

1  1 

AHRS  1  1  ms  I 

Figure  ^-1  Steps  of  Integration 


When  using  non! ntegrated  separate  sensor  blocks,  it  is  necessary  to  employ  four  Indepen¬ 
dent  channels  for  flight  control  purposes  and  a  duplex  sensor  package  for  both 
a t t i tude / headl ng  and  navigation  tasks.  This  leads  to  a  maximal  configuration  and  to  the 
use  of  plurality  of  sensors  for  rates  and  accelerations. 

One  configuration  described  below  is  to  use  an  EAP/AMSU^ ’ -sys tem  together  with  one  INS. 
This  AMSU-system  is  the  result  of  the  first  step  of  Integration  outlined  In  figure  U-i. 
It  provides  flight  control  data  for  stability  augmentation  and  the  autopilot  function  of 
an  Inherently  unstable  aircraft,  and  redundant  attitude  and  back-up-navlgatlon  Informa¬ 
tion.  This  system  Is  already  an  integral  part  of  the  EAP-FCS  and  has  successfully  com¬ 
pleted  flight  trials. 

In  the  next  development  step  the  flight  control  sensors,  the  attitude/heading  determina¬ 
tion  and  the  navigation  functions  are  combined  Into  one  system.  The  principle  procedure 
for  developing  such  a  system  and  the  arising  risks  will  be  discussed  in  chapter  &.?. 


Secondary  Attitude  and  Heading  Determination  System 
Aircraft  Motion  Sensor  unit 
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♦  t  ♦  Combination  of  Flight  Control  and  AHRS  Functions 

AS  already  Indicated  In  the  introduction,  there  are  at  least  two  approaches  to  the 
Integration  of  inertial  data  into  an  airhorne  weapon  system.  The  AMSU  approach  combines 
the  determination  of  angular  rate  and  linear  displacement  with  the  provision  of  attitude 
and  heading  Euler  angles. 

The  AMSU-system,  the  main  features  of  which  are  shown  in  table  has  been  developed 
especially  to  suit  the  requirements  of  the  EAP-FCS.  It  provides  high  bandwidth,  fresh 
and  highly  reliable  low  noise  data  in  order  to  achieve  good  handling  quality  and  stabil¬ 
ity  of  tne  aircraft.  In  addition,  the  system  provides  attitude,  heading,  inertial  vert¬ 
ical  speed  and  inertial  altitude. 


mass 
vol ume 
redundancy 
range 


output 

bandwidth 
St  al eness 
avallabil ity 


39.2  kg 

38.0  1 

quadruplex 

250“/a 

t25*/3 

85  Vs 

12g 

512  Hz 
42  Hz 

45  Hi 

2,5  ms 
9-  10"'^’ 

2- 10"^ 


(4  boxes) 

(4  boxes) 

roll  rate 
yaw  rate 
pitch  rate 
accelerations 
rates,  accelerations 
attitude,  heading 
rates,  accelerations 

rates,  accelerations  excluding  filters 
probability  of  loss  of  aircraft  due  to  AMSU/FCC 
probability  of  loss  of  aircraft  due  to  FCS 


Table  4-1  Main  Features  of  the  E AP /A MSU-Sy s tern 

The  function  as  a  sensor  for  flight  control  data  and  at t i t ude/ hea dl ng  determination 
imposes  a  particular  structure  on  the  AMSU  system.  The  pulse  counts  delivered  from  the 
gyros  and  accelerometers  are  scaled,  compensated  and  output  at  a  frequency  of  512  Hz  by 
a  fast  TMS  320  processor.  Two  MC  68000  microprocessors  In  parallel  compute  the  attitude 
and  heading  equations  along  with  internal  bullt-ln-tests  .  These  tasks  are  carried  out 
at  a  frequency  of  42  Hz.  The  initial  heading  Is  obtained  by  autonomous  gyrocompassing . 
The  interconnection  of  the  AMSU  with  the  flight  control  computer  uses  a  dedicated  serial 
digital  link.  The  interconnection  of  the  AMSU-system  with  the  quadruplex  flight  control 
computer  is  shown  in  figure  4-2  below. 


Figure  4-2  Interconnection  EAP/AMSU  -  Flight  Control  Computer 

The  roll,  pitch  and  yaw  rates  are  measured  In  each  box.  In  addition  each  box  contains 
three  dry,  force  rebalanced  B-280  accelerometers  in  an  orthogonal  configuration. 

In  order  to  suit  the  high  dynamics  of  a  CCV,  the  measurement  ranges  for  rates  and 
acceleration  are  respectively  set  to  max.  250®/s  and  12  g.  The  bandwidth  capability  and 
data  latency  of  the  angular  rates  and  accelerations  are  better  than  45  Hz  and  2,5  ms 
respectively,  excluding  aircraft  structural  filter  and  anti-aliasing  filter  transfer 
functions . 

As  Integrity  is  very  important  for  flight  safety  critical  equipment  it  should  be 
recalled  that  the  MTBF  of  the  LTR-8l'^  which  Incorporate?  two  K-273  gyros  and  three  p- 
280  accelerometers  exceeds  10,000  hours  proven  within  more  t'han  400,000  equipment  flight 
hours  in  the  commercial  transport  aircraft  environment.  Under  the  above  mentioned  con¬ 
ditions  this  gyro  has  shown  a  MTBF  of  more  than  100.000  h.  To  our  knowledge  these  fig¬ 
ures  are  presently  higher  than  the  equivalent  number  experienced  with  APING  705  RLC- 
IRS^3  in  the  same  environment. 


LITTON  Transport  Reference  1981 

Ring  Laser  Gyr o -I ner t I al  Reference  System 
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The  effort  required  to  adapt  an  AMSU-syeten  for  EFA^**  is  nalnly  to  reduce  weight  and  to 
Improve  integrity  from  the  EAP/AHSU.  In  parallel  with  these  improvements  the  complexity 
can  be  reduced  by  accounting  for  the  fact  that  duplex  redundant  Euler  angles  are  suffi¬ 
cient  and  twelve  accelerometers  would  not  be  required.  The  goal  to  reduce  the  weight 
can  be  achieved  by  combining  two  completely  independent  angular  rate  channels  with  one 
attitude  channel  in  one  housing.  This  will  lead  to  a  two  box  solution  including  a  qua- 
druplex  angular  rate  and  acceleration  output  and  duplex  at 1 1 1 ude/ head  1 ng  output.  A 
housing  concept  of  ATR  size  la  shown  ip  figure  0-3  below. 


Figure  0-3  EFA/AMSU  System 


0.2,  Combination  of  Flight  Control  and  Navigation  Functions 

Any  development  of  an  Integrated  system  for  flight  control,  a t t I tude/ headl ng  determina¬ 
tion  and  navigation  functions  has  to  consider  the  impact  on  safety  and  operation  of  the 
whole  aircraft.  For  a  CCV  application  It  is  typically  required  to  have  available  qua- 
druplex  redundancy  for  the  stability  augmentation  data,  duplex  redundant  attitude  and 
simplex  autoQomous  navigation  data. 

It  is  necessary  to  use  strap  down  technology,  as  opposed  to  a  platform  system,  because 
the  latter  does  not  deliver  sufficiently  fresh  stability  augmentation  data  due  to  the 
necessity  of  differentiating  the  Euler  angles  and  subsequent  filtering  of  the  noise  gen¬ 
erated  . 

In  order  to  reduce  vulnerability  it  Is  advisable  to  split  the  system  into  two  boxes, 
each  of  which  is  designed  to  deliver  both  navigation  and  flight  safety  critical  data. 

For  non-augmented  medium  accuracy  IMS's  laser  gyros,  of  weight  1.2  kg  and  an  accuracy 
better  than  0.01  •/h  corresponding  to  a  path  length  of  25  cm,  are  required. 


Fatmesftk  90  Vm  l«tr  (a) 

Figure  Errors  of  Laser  Gyros 
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European  Fighter  Aircraft 


To  Obtain  the  demanded  quadruple  redundancy  using  orthogonal  measurement  axes,  u  x  ?  » 

12  RLG's  would  be  required.  It  can  be  shown  however  that  six  skewed  mounted  RLC's, 
three  in  each  box  orthogonal  to  one  another,  are  sufficient  for  the  necessary  redun¬ 
dancy  . 

During  the  development  stages  on  an  Integrated  system  the  following  points  have  to  be 
considered: 

Evidence  of  Integrity  should  be  provided. 

The  INS  should  have  at  least  three  RLG's. 

The  system  should  be  repackaged  in  such  a  way  that  the  safety  and  redundancy 
requirements  are  satisfied. 

-  The  sensor  block  should  be  rotated  so  that  it  Is  skewed  In  relation  to  the  housing. 

Independent  self-contained  electronics  for  each  flight  safety  critical  rate  channel 
should  be  provided. 

The  individual  channels  should  be  mechanically  Isolated  by  walls. 

The  safety  critical  software  and  software-tests  should  be  developed  to  appropriate 
standards . 

An  appropriate  redundancy  management  and  BIT^^  Is  required. 

The  filters,  time  delays  and  accuracies,  which  depend  on  the  performance  of  the 
aircraft  should  be  discussed  with  the  people  responsible  for  flight  control. 

-  A  new  flight  control  computer  should  be  developed  (if  integrated). 

An  appropriate  location  for  the  system  in  the  aircraft  should  be  established. 

.  3 «  Main  Problem  Areas 

The  main  problem  and  risk  areas  arising  during  the  development  of  the  Integrated  “yolem 
are: 

Vibration  Isolators 
Data  processing 
Redundancy  management 

-  Separation  of  the  system 

These  points  are  discussed  in  detail  below. 


4 ♦  3 . 1 .  Vibration  Isolators 

There  are  generally  three  kinds  of  translational  vibrations  specified,  namely; 

*  vibrations  Induced  by  aerodynamical  effects 
vibrations  Induced  by  engines 
vibrations  Induced  by  gunblast 

The  specified  spectra,  especially  In  low  frequency  ranges,  occur  seldom  In  practice.  In 
reality  the  vibration  spectra  have  RMS^^-values  which  are  approximately  ten  times  less. 
It  Is  left  up  to  the  customer  to  decide  whether  the  spectra  are  used  for  a  realistic 
simulation  environment  or  only  to  test  the  system  under  extreme  conditions. 

When  choosing  the  vibration  Isolators  and  the  sensor  block  mounting  method  it  is  neces¬ 
sary  to  take  Into  account  the  bandwidth  of  the  flight  dynamics  of  the  aircraft. 

A  high  bandwidth  requires  high  natural  frequencies  of  the  vibration  isolators  and  a 
corresponding  hard  mounting  of  the  sensor  block.  The  vibration  power  at  the  sensor 
block  increases  with  the  natural  frequency  of  the  vibration  isolators  so  that  the  burden 
on  the  sensors,  along  with  the  resulting  errors,  rise.  it  can  be  said  that  the  sensor 
errors  and  the  subsequent  navigation  accuracies  are  almost  proportional  to  the  square  of 
the  vibration  power.  Due  to  this  fact  it  is  necessary  to  use  soft  vibration  Isolators 
for  appropriate  navigation  accuracy. 

Typical  frequencies  are  shown  in  the  following  diagram. 


Bull t-In-Test 
Root  Mean  Square 
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Figure  4-5  Frequencies  for  Flight  Control  Purposes 

Isolators  corresponding  to  Inertial  navigation  systems  have  natural  frequencies  of 
around  20  to  40  Hz  at  20'’C  and  a  t ransnl ss  1  bl  1 1  ty  of  about  4  to  6.  For  flight  control 
purposes  however,  a  value  almost  twice  as  high  Is  required  depending  on  the  high 
bandwidth  (6  Hz)  of  modern  inherently  unstable  aircraft.  This  value  can  vary  with  low 
temperatures  and  high  vibration  levels  by  a  factor  of  1.5  up  to  120  Hz,  The  effect  of 
this  is  to  decrease  the  accuracy  of  the  navigation  by  a  factor  of  about  4. 

It  can  be  concluded  that  the  choice  of  the  vibration  Isolators  depends  on  the  one  hand 
on  the  high  dynamics  of  the  aircraft  and  on  the  other  hand  on  the  soft  mounting  of  the 
sensor  block  necessary  to  obtain  the  required  navigation  accuracy. 

In  order  tc  reduce  the  t em pe r ature -de pendent  variation  of  the  natural  frequency  It  Is 
useful  to  define  an  appropriate  temperature  range.  The  choice  of  the  elastomeres  for 
the  isolators  can  be  made  optimal  by  restricting  the  temperature  range.  This  reduces 
the  variation  in  the  natural  frequency  and  transnl ssl bil 1 t y  of  the  Isolators,  as  shown 
In  figure  4-6.  In  general  a  small  variation  in  the  el genf requency  can  be  achieved  at 
i.he  cost  of  a  high  variation  of  the  transmi  ssl  bll  1 1  y  and  vice  versa.  These  problems 
can  be  alleviated  however  by  either  limiting  the  temperature  range  or  by  Installing  a 
sensor  block  heater,  if  the  application  allows. 


Figure  4-6  Variation  of  the  Natural  Frequency  and  T r ansm l s s I bl 1 1 1 y 
with  Temperature 


When  mounting  the  sensor  block  it  is  very  important  to  consider  that  the  rotational  and 
translational  natural  frequencies  vhereof  are  wide  apart.  The  reason  for  this  Is  that 
the  coupling  of  the  translational  Into  the  rotational  vibrations  decreases  with  the 
increasing  difference  of  their  el genf requencles .  Rotational  vibrations  of  the  sensor 
block  will  cause  the  angular  rates  of  the  aircraft  to  be  Incorrectly  determined. 

A  non - 1 soel as 1 1 c  mounting  of  the  sensor  block  causes  transformation  of  translational 
into  rotational  vibrations  and  produces  dither  Induced  coning  motion.  An  optimal  mount* 
ing  for  a  cubic  sensor  block  can  be  achieved  using  four  isolators  forming  a  tetrahedron. 
If  the  space  available  allows.  This  solution  win  produce  a  ratio  between  the  rota¬ 
tional  and  translational  el genfrequencles ,  approaching  the  maximum  attainable  value  of 
two . 

If  the  static  and  dynamic  mass -unbalance  of  the  sensor  block  is  known,  then  it  is  possi¬ 
ble  to  determine  the  rotation  of  the  sensor  block  from  the  specified  translational 
vibrations  by  use  of  the  transfer  function.  By  this  method  It  Is  possible  ••  o  compute 
system  errors  like  coning  and  sculling  and  their  effect  on  navigation  accuracy. 


Another  important  aspect  to  he  considered  Is  the  effect  of  the  hard  Isolators  on  the 
dither  behaviour  of  the  laser  gyro.  The  laser  gyro  is  connected  via  a  dither  spring  of 
high  rotational  t r ansa  1 ss i bi 1  i ty  (300)  to  the  sensor  block,  which  in  turn  Is  wcunted  cr 
Isolators,  as  shown  in  figure  4-7.  It  can  be  shown  using  the  theory  of  coupled  oscilla¬ 
tors  that  the  effective  t r ansml ssi b 1 1 i t y  of  the  dither  spring  depends  on  the  natural 
frequency  of  the  isolators. 


Figure  4-7  Mounting  of  the  Laser  Gyro  Block 

If  the  effective  Q  of  the  dither  spring  falls  to  a  value  in  the  region  of  150  then  the 
Isolators  will  absorb  too  much  energy  from  the  dither  driver  and  furthermore  the  excita¬ 
tion  of  the  actual  glass  block  of  the  RLC  will  become  so  weak  that  the  lock-in  threshold 
cannot  be  overcome.  This  limits  the  frequencies  of  the  vibration  isolators.  Figure  4-8 
shows  how  the  effective  Q  decreases  with  the  Increasing  resonant  frequency  of  the  Isola¬ 
tor  . 


Figure  4-8  Variation  of  the  Transml ssl bl 1 1 ty  of  the  Dither  Spring 


4.3.2.  Data  processing 

An  important  problem  area  in  the  integration  of  navigation  and  flight  control  systems  is 
the  definition  of  the  required  flight  control  filters  and  their  time  delays.  The  time 
delay  is  not  much  of  a  problem  for  at 1 1 tude 'headl ng  determination  and  for  navigation 
purposes . 

The  filters  are  divided  into  two  categories  -  high  speed  and  low  speed.  The  high  speed 
filters  have  to  reduce  the  dither  and  quant  I  sat i on -1 nduce d  gyro  noise.  The  computational 
frequency  of  these  filters  has  to  be  identical  with  the  sampling  frequency  of  the  data 
(2048  Hz).  These  filters  typically  produce  a  time  delay  of  about  5  ms.  Sensor  error 
compensation,  along  with  the  transformation  to  orthogonal  measurements,  reasonableness 
tests  and  BIT,  produce  a  further  2.5  ms  time  delay.  The  resulting  data  are  finally  com¬ 
pensated  for  structural  modes,  isolators,  autopilot  characteristics,  etc.  using  the  low 
speed  filters.  Typical  transfer  functions  and  sensor  noise  characteristics  are  shown  in 
figure  4-9, 
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Figure  4-9  Transfer  Functions  and  Sensor  Noise 
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The  time  delay  associated  with  those  filters  mainly  depends  on  the  algorithms  used  and 
is  approximately  5  ms  including  the  data  transfer  to  the  flight  control  computer.  This 
yields  a  total  time  delay  of  12.5  ®s  which  corresponds  to  an  excess  phase  of  at  to 
Hz . 

When  using  skewed  sensor  axes  it  is  important  to  ensure  that  the  measurements  are  made 
simultaneously.  If  this  is  not  the  case  then  the  transformation  to  aircraft  axes  frame 
will  lead  to  grave  errors  in  the  flight  control  domain.  a  typical  value  for  the  time 
synchronisation  is  0.02  ms.  A  possible  solution  to  this  problem  is  high  speed  data 
transfer  or  processor  synchronisation.  If  connection  wires  for  processor  synchronisation 
are  used  then  this  could  lead  to  single  point  failures  which  of  course  are  to  be 
avoided. 


.  3  ♦  3 .  Redundancy  Management 

An  important  point  in  the  design  of  an  integrated  system  Is  the  de ve  1  opmen of  an  effi¬ 
cient  RM^*^.  In  principle  the  RM  is  carried  out  in  three  stages; 

The  first  step  Is  the  failure  detection  procedure,  which  distinguishes  between  hard  and 
soft  failures.  Hard  failures  have  to  be  detected  within  50  ms  via  BIT  procedure, 
whereas  the  soft  failure  detection  can  be  somewhat  longer. 

The  second  step  Is  the  Isolation  of  the  failure  using  respectively  BIT  and  oarlty  equa¬ 
tions  for  hard  and  soft  failures.  The  choice  of  the  thresholds  necessary  for  the  parity 
equations  depends  on  the  required  accuracy  of  the  flight  control  data,  on  the  noise  ’ev- 
els  of  the  sensors  and  on  the  dynamics  of  the  aircraft.  In  order  to  avcid  false  alarm 
it  is  necessary  to  take  Into  account  structural  bending  when  using  a  system  with  two 
boxes  separated  In  the  aircraft. 

The  third  step  Is  the  reconfiguration  of  the  system  after  an  artslnc  failure.  This  is 
achieved  by  design  equations  which  transform  the  Intact  skewed  measurements  Into  crthoti- 
onal  measurements  taking  into  account,  however,  any  switching  transients. 

The  detection  and  isolation  of  the  failures  and  the  reconfiguration  of  the  system  intro¬ 
duce  a  time  delay  which  has  to  be  added  to  the  existing  failure  detection  time  delays. 
One  of  the  most  important  points  is  to  consider  the  single  point  and  common  mode 
failures  which  subsequently  lead  to  the  loss  of  the  whole  aircraft.  Some  cT  »hese 
failures  due  to  the  sensor  package  for  flight  control  are  listed  below; 

broken  isolator 

open  latch  In  the  mounts 

wrong  software  (common  mode  failure) 

defect  busses 

etc  . 


**.3.^.  Separation  of  the  System 

Vulnerability  makes  it  necessary  to  split  the  system  into  two  boxes.  This  leads  to  sen¬ 
sor  location  problems  In  the  aircraft.  A  solution  to  this  problem  could  te  to  search 
for  an  optimal  location  in  the  aircraft  which  depends  on  the  fuselage  bending  nodes  and 
antinodes.  it  is  necessary  to  pay  attention  to  the  effect  of  aircraft  bending  and 
vibration  on  the  distributed  system  and  to  provide  a  rigid  mounting  structure. 

Another  problem  to  be  solved  is  the  making  of  safety  critical  and  mission  C'*ltlcal  chan¬ 
nels  independent,  because  a  failure  In  the  mission  critical  part  must  not  influence  the 
safety  critical  outputs.  This  can  be  solved  by  sharing  no  components  between  the  chan¬ 
nels  and  by  separating  instrument  power  and  data  channels  both  electrically  and  spa- 
clally,  Furthermore  the  system  must  he  protected  against  s I ncl e -pc  1 nt  fallurfs  and  the 
cross -channel  communications  must  be  minimised.  The  use  of  resistors  or  diodes  prevents 
failure  propagation.  All  these  methods  lead  to  an  increasing  weight,  power  consumption 
and  size. 


5 .  C  oncl us i ons 


Described  in  this  paper  are  two  steps  for  the  integration  of  flight  control  sensors, 
AHRS  and  INS.  It  has  been  shown  that  the  use  of  the  same  sensors  for  flight  control  and 
AHRS  functions,  as  for  example  In  the  AMSU-system,  yield  excellent  results.  The  AMSU- 
system  has  already  demonstrated  Its  performance  capability  In  the  EAR  inherently 
unstable  aircraft.  It  has  to  be  stated  that  these  aircraft,  as  opposed  to  conventional 
aircraft,  require  inertial  sensor  data  with  an  extremely  high  bandwidth  and  very  small 
data  latency  for  flight  control  purposes. 

The  integration  of  flight  control  sensors  and  INS  in  one  system  Is  basically  feasible 
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and  has  already  been  successfully  implemented  In  commercial  aircraft.  The  development 
of  an  integrated  system  using  dithered  laser  gyros  for  inherently  unstable  aircraft 
involves  considerable  risks  even  when  state  of  the  art  techniques  are  employed.  Thi*^  is 
due  to  the  fact  that  such  systems  require  a  compromise  between  flight  control  require¬ 
ments  and  navigation  .accuracy.  Furthermore,  systems  of  the  second  step  of  integration 
lead  to  no  substantial  saving  in  weight  or  space,  as  demonstrated  by  IISA. 

Taking  development  risks  into  account,  the  cost  of  an  Integrated  system  is  higher  t nan 
that  for  separate  systems  or  systems  of  the  first  integration  step. 
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DISCUSSION 


J.Nkol,  UK 

The  reliability  of  the  dcscribetl  system  is  based  upon  hardware  redundancy.  What  steps  have  been  taken  to  ensure 
comparable  software  reliability,  particularly  in  the  micrtKHxie  of  unit  prtK'cssors  .* 

Author's  Reply 

The  three  main  steps  of  code  walkthrough  (i  e.,  module  test,  hardware  integration,  and  software  integration)  ha'  e  been 
accomplished.  A  computer-aided  simulation  was  conducted  to  lest  alt  instructions  implemented  in  the  microprcKessors. 
The  test  results  have  been  d<K'umented  in  a  lest  matrix  that  compares  software  requirements  with  test  steps.  The  testing 
and  intensive  reviews  covered  about  5(1  percent  <if  the  software  development 
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SU1WARY 


While  new  technologies  offer  the  avionics  designer  opportunities  In  terms  of  providing  systems  with 
expanded  capabilities,  those  opportunities  are  accompanied  by  new  kinds  of  challenges  and  constraints 
which  warrant  a  revision  of  traditional  design  life  cycle  strategies.  The  trend  of  for  Increasing 
complexity  and  cost  In  emerging  avionics  systems,  driven  by  requirements  for  Increased  functional 
capability,  has  created  a  need  for  a  predictive  analytical  methodology  wh.ch:  H)  accurately  forecasts 
system  performance  early  In  the  design  process,  and  (2)  treats  the  human  operator  and  the  equipment  as  a 
fully  Integrated  man-machine  system.  A  methodology  which  meets  tnese  needs  has  been  developed  and 
validated  at  Bell  Helicopter  Textron.  The  process  Is  being  used  to  provide  early,  accurate  avionics 
system  characterization,  thereby  reducing  design  costs. 

THE  PROBLEM 


The  applications  of  advanced  technologies  In  combat  aircraft  offer  the  avionics  designer  both 
opportunities  and  constraints  from  a  man-machine  Interface  perspective.  Many  of  the  functions 
traditionally  performed  by  the  human  operator  can  be  automated.  With  Innate  human  capabilities  remaining 
essentially  constant,  the  designer  has  the  opportunity  to  provide  more  total  system  capability,  Improve 
combat  mission  effectiveness  and  provide  the  operator  a  workplace  which  optimizes  his  mental  ar  i  physical 
capacities.  Tt-e  modern  avionics  designer  must.  In  fact,  exercise  this  opportunity.  The  demands  of 
current  and  future  battlefields  dictate  expanded  man-machine  system  capability  and  performance. 

Advanced  technology  applications  also  Impose  new  kinds  of  complex  challenges  and  constraints.  These 
challenges  and  constraints  are  created.  In  part,  by  the  pace  of  technology  development  and.  In  part,  by  a 
new  category  of  problems  which  the  advanced  technology  opportunities  cause.  The  challenges  and 
constraints—  “the  problem"  --Is  that  the  fielding  of  an  advanced  avionics  system  Is,  by  and  large,  a  race 
against  time.  The  advanced  system  must  remain  effective  against  a  battlefield  environment  which  Is  highly 
dynamic.  As  threat  capabilities  change,  so  must  system  capability.  If  the  des1gn-to-f1eld1ng  process  Is 
out-paced  by  battlefield  demands,  sub-optimum  systems  are  fielded.  While  this  system  capability  versus 
threat  demand  game  of  "leap  frog"  Is  ultimately  a  fact  of  life  despite  the  time  cycle  of  the  development 
process,  the  application  of  advanced  technology  has  created  a  new  category  of  design  Issues  which 
threatens  to  lengthen  our  processes  even  further.  The  nature  of  advanced  avionics  systems  forces  a  close, 
near-complete  functional  Integration  of  man  and  machine.  Successfully  coping  with  this  level  of 
Integration  goes  beyond  the  traditional  human  factors  engineering  concerns  associated  with  avionics 
design.  The  man-machine  Interface  issues  have  become  vastly  more  complex.  The  designer  Is,  in  fact,  now 
confronted  with  the  problem  of  predicting  both  man  and  machine  performance,  as  both  elements  operate  as 
one  total,  highly  complex  system.  Predicting  system  performance  Is  the  Issue  that  confronts  us; 
efficiency  In  the  design  process  Is  the  objective. 

Predicting  the  performance  of  the  "machine  part"  of  the  man-machine  system  Is  relatively  mature.  Accurate 
predictions  of  how  equipment  will  perform  are  quantifiable  and  normally  done  with  confidence.  However, 
when  the  human  operator  Is  added  to  the  system,  predictive  methods  traditionally  become  less  quantifiable 
and  subjectivity  reigns.  The  traditional  answer  to  this  dllenna  Is,  too  often,  a  series  of  Inefficient 
and  expensive  part-task  studies,  simulations  and  flight  tests  which,  when  compared  to  the  quantification 
of  machine  performance,  appears  to  approach  trial  and  error.  Compoundirg  the  problem  Is  the  fact  that 
these  kinds  of  human  performance  predictions  traditionally  occur  well  Into  the  design  process  when  system 
configui atlon  changes  are  more  costly.  To  avoid  this  situation.  It  is  necessary  to  validly  predict,  at  an 
early  point  In  the  design  process,  that  both  elements  of  the  man-machine  system  will  perform  adequately  to 
meet  system  performance  requirements. 

A  NEW  APPROACH 

Traditionally,  the  fidelity  of  performance  predictions  has  maintained  s  linear  relationship  with  the 
design  life  cycle  process.  Performance  predictions  become  Increasingly  valid  as  the  design  matures 
because  adequate  data  Is  not  available  earlier.  Unfortunately,  the  cost  of  design  changes  also  Increases 
with  design  maturity.  This  problem.  Illustrated  In  Figure  1,  becomes  more  acute  as  the  complexity  and 
cost  of  avionics  systems  Increases. 

If  more  valid  system  performance  predictions,  based  on  more  adequate  data,  are  made  early  In  the  design 
process,  the  relationship  between  design  changes,  the  design  life  cycle,  and  cost  can  be  reversed.  This 
concept  Is  Illustrated  In  Figure  2. 

It  Is  Important  to  note  (Figures  1  and  2)  that  the  relative  emphasis  p'aced  on  analysis  and  man-ln-the- 
loop  simulation  has  Increased.  It  Is  essential  to  understand  that  the  Increased  analytical  emphasis  Is 
more  than  simply  Increased  time  spent  on  the  process.  The  analysis  referenced  Is  a  methodology  which  has 
been  developed  by  Bell  Helicopter  to  support  the  design  of  advanced  avionics  systems  which  depend  on 
optimized  man-machine  Integration.  This  analytical  methodology  has  been  validated  on  several  advanced 
avionics  development  programs  and  provides  quantitative  performance  data  for  the  aggregate  man-machine 
system. 
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Design  Process  (Time) 


Figure  1.  Traditional  Design  Approach 


Design  Process  (Time) 


figure  ?.  Suggested  Design  Approach 


The  methodology  Is  unique  in  that  It  treats  the  crewinember(s)  and  the  avionics  equipment  package  as  equal 
parts  of  a  total  system  that  must  interact  to  perform  a  task.  Human  and  equipment  performance  are 
quantified  to  determine:  (1)  if  the  man/machine  system  succeeded  or  failed  in  a  given  situation,  and  (2) 
why  success  or  failure  occurred.  The  five  major  elements  of  the  methodology  process  and  examples  of 
predictive  validity  are  discussed  in  the  following  narratives. 

ELEMENT  1  -  MISSION  FUNCTION  REQUIREMENTS  ANALYSIS 

The  first  element  of  the  methodology  Is  Mission  Function  Requirements  Analysis.  Analytical  processes  In 
this  element  include  requirements  from  MIL-H-46855B  combined  with  techniques  from  operations  analysis, 
systems  engineering  and  human  factors  engineering.  Figure  3  provides  a  schematic  representation  of  this 
element. 
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Figure  3.  Mission  Function  Requirements 


Oetelled  mission  sceneries  ere  developed  thet  reflect  the  bettiefleld  environment  projected  for  the  system 
being  designed.  As  shown,  cendidete  sceneries  end  mission  profiles  ere  besed  on  e  verlety  of  Inputs.  The 
objective  here  Is  to  develop  en  eccurete  reel  world  erene  In  which  the  men-mechlne  system  will  be 
evelueted.  The  eccurecy  of  this  cherecterizetlon  Is  criticel  end  depends  heevlly  on  both  subject  metter 
expert  Involvement  end  e  detelled  understending  of  threet  cepebllltles  end  operetlonel  requirements. 

Severel  mission  profiles  ere  normelly  needed  to  execute  the  totel  scenerlo.  These  profiles  ere 
constructed  to  reflect  customer-defined  missions,  tectics,  cepebllltles  of  the  conceptuel  evlonics 
equipment  end  eirfreme,  end  threet  cepebllltles.  Severel  detelled  enelyticel  bettleflelds  ere  developed 
by  loceting  threets  In  reel  world  terrein  end  plenning  mission  operetlons  which  reflect  ectuel  operetlonel 
problems:  e.g.  weether,  dey/night,  verlent  threet  formetlons,  etc.  Profiles  ere  sufficiently  detelled  to 
support  enelysis  In  one-  to  two-second  time  segments. 

Mission  profiles  ere  digitelly  represented  end  enelyzed  vie  computer  mission  models.  Models  used  conteln 
terrein  topogrephy  and  feeture  dete,  threet  formetlons,  Intervisibllltles,  etc.;  end  the  mission  profile. 
The  results  of  this  misslon/scenerlo  enelysis  (figure  3)  Include  dete  such  es  detelled  threet  response 
times,  threet  end  own-system  Acquisition  windows,  end  response  times  required  for  the  men-mechlne  system 
to  Accomplish  mission  tesks. 

This  process  Allows  the  designer  considereble  flexibility  In  thet  e  verlety  of  conceptuel  equipment 
options  mey  be  cherecterlzed  end  evelueted  egelnst  severel  bettiefleld  situetlons.  Cendidete  equipment 
arrays  can  be  evaluated  to  determine  factors  such  as  required  Input/output,  processing  time  available, 
alternate  modes  of  operation  and  total  operating  timelines  for  the  man-machine  system. 

ELEMERT  2  -  CAKDIDATE  SYSTEM  DEVELOPMENT  AMD  GROSS  TASK  ANALYSIS 

The  second  element  of  the  methodology.  Candidate  System  Development  and  Gross  Task  Analysis,  refines  the 
general  mission  function  data  developed  In  element  1.  As  shown  In  Figure  4,  the  candidate  equipment 
package  options  are  evaluated  and  refined  end  candidate  equipment  Items  are  selected  to  work  toward  the 
objective  of  a  baseline  mission  equipment  package. 


Figure  4.  Candidate  System  Development  and  Gross  Task  Analysis 
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Early  In  the  analysis,  the  candidate  systens  and  technologies  nay  range  froa  real,  I.e.  state-of-the-art 
Hens,  to  purely  conceptualized  characterizations  of  out-year  technology,  depending  on  the  design 
requireaents  at  hand.  Froa  candidate  systeas  and  technologies,  candidate  systea  equipaent  packages  are 
developed.  Cockpit  layouts  and  soft  aockup  studies  add  data  to  suppleaent  the  alsslon  function 
requireaents  previously  deteralned,  and  a  baseline  alsslon  equipaent  package  configuration  Is  developed. 
To  provide  aan-aachine  Interface  definition  and  prepare  data  for  subsequnet  man-machine  systea  perforaance 
analysis,  a  gross  task  analysis  Is  also  completed  at  this  point  In  the  process. 

A  functional  “road  aap“  Is  created  to  provide  a  gross  definition  of  both  the  flow  and  task  descriptors  of 
each  mission  profile.  The  content  of  these  block  flow  diagrams  (Figure  5)  Is  referred  to  as  Level  1 
Analysis. 


Figure  5.  Example  of  Level  1  Analysis 


Level  1  odta  Is  used  to  establish  Initial  systea  design  requirements  for  controls,  displays  and  general 
boundaries  for  equipaent  operating  timelines.  When  complete,  the  first  element  of  the  methodology 
establishes  the  man-machine  system  mission  function  requireaents.  Data  available  at  this  point  In  the 
process  allows  the  designer  to: 

(1)  Determine  the  top  level  functions  the  man-machine  system  must  perform  (e.g.  communicate,  navigate, 
etc.)  and  when  those  functions  must  occur  In  the  profile. 

(2)  Define  time  boundaries  that  the  man-machine  systea  must  function  within  to  be  mission  effective. 

(3)  Characterize  the  equipment  package  at  a  gross  level  In  terms  of  Information  Input/output, 
processing  requirements,  etc. 

During  this  phase  of  the  analysis,  gross  tasks  are  Identified  and  characterized  to  a  second  and  third 
detail  level.  This  process  Is  Illustrated  In  Figures  6  and  7.  The  Level  3  analysis  characterizes  tasks 
to  a  "check  list"  level  and,  as  noted  by  referencing  Figure  7,  Is  near  to  becoming  system  snecific. 


z.a 


Figure  6.  Example  of  Level  2  Analysis 
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Figure  7.  Example  of  level  3  Analysis 


ELEHEn.  3  -  CRITICAL  TASK  ANALYSIS 

The  third  element  of  the  methodology  Is  critical  task  analysis.  It  Is  here  that  the  analytical  process 
definitely  departs  from  the  more  traditional  human  factors  processes  In  that  the  crew  member(s)  and  the 
equipment  package  are  treated  as  a  single  system.  Both  system  elements  (man  and  machine)  have  critical 
tasks  that  must  be  evaluated  to  accurately  predict  total  system  performance.  The  critical  task  analysis 
process  Is  Illustrated  In  Figure  8. 


Figure  8.  Critical  Task  Analysis 

Critical  tasks  are  selected  on  the  basis  of  MIL-ST0-46855B  criteria;  I.e.  tasks  which  can  adversely  affect 
mission  performance,  system  accuracy,  or  operator  safety  when  either  not  performed  or  performed  outside 
required  time  or  sequence  parameters.  The  rationale  for  concentrating  on  the  critical  tasks  Is  that  these 
tasks  are  the  true  system  design  drivers.  The  objectives  of  this  analytical  phase  are  to:  (1)  develop 
very  detailed  task  descriptions,  and  (2)  establish  timelines  for  each  task.  To  meet  the  first  objective, 
each  critical  task  Is  defined  to  Its  lowest  operational  element.  An  example  of  the  lowest  operational 
element  or  “subtask"  for  a  crew  member  Is  a  line  address  key  selection  on  a  multifunction  display.  A 
subtask  example  for  an  equipment  Item  might  be  the  fleld-of -regard  scan  time  for  a  target  detection 
system. 


After  critical  tasks  are  defined  to  the  required  level,  performance  times  and  variances  are  determined  for 
each  subtask.  This  process  Is  the  basis  for  determining  what  must  be  per'ormed  by  the  man-machine  system 
and  how  much  time  Is  required  to  perform  It.  At  this  point  In  the  overall  analytical  process,  critical 
subtasks  have  been  Identified  and  performance  times  for  each  have  been  determined.  These  data,  coupled 
with  the  time-based  forcing  factors  developed  during  the  first  element  of  the  methodology,  provide  Input 
to  the  man-machine  performance  analysis. 


ELEMENT  q  -  SYSTEM  PERFORMAhCE  ANALTSIS 


Element  four  of  the  analytical  methodology  employs  a  computerized  system  performance  model  to  determine  If 
the  man-machine  system  can  perform  critical  subtasks  within  required  timelines.  A  schematic 
representation  of  element  four  Is  shown  In  Figure  9. 
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Figure  9.  Systea  Perforaence  Analysis 


The  systea  perforaance  aodel  used  1s  the  Sequiter  Workload  Analysis  System  (SWAS).l  This  microcomputer 
based  digital  slaulatlon  aodel  employs  an  expert  systea  approach  In  Its  architecture.  Is  relatively  easy 
to  use,  and  nas  tne  nigniy  oesiraoie  teatures  ot  ainiauing  subjectivity  and  allowing  for  analysis  of 
concurrent  tasks. 

The  SUAS  model  yields  detailed  output  In  both  tabular  and  graphical  format.  Using  this  Information,  the 
analyst  can  make  decisions  regarding  Issues  such  as:  (1)  the  probability  of  mission  success,  (2)  the 
times  required  by  both  the  crew  member(s)  and  equipment  suite  to  accomplish  mission  tasks,  (3)  the 
workload  distribution  between  crew  members  (where  multiple  operators  are  Involved),  and  (4)  task 
"bottlenecks"  generated  by  task  time  sharing  overloads  or  delays  caused  by  tasks  not  completed  on  time. 

At  this  point  In  the  analysis,  the  avionics  systea  designer  has  quantifiable  performance  data  which  can  be 
used  to  support  a  variety  of  decisions.  For  example.  If  the  analytical  data  Indicated  that  the  man- 
aachlne  system  being  considered  could  not  complete  all  critical  subtasks  In  the  time  available,  the 
designer  could  examine  the  output  data  to  determine  where  the  time  or  task  bottlenecks  occurred.  Since 
both  human  operator  and  equipment  performance  data  are  available,  the  designer  could  determine  which  part 
of  the  man-machine  system  was  requiring  excessive  time  and  where.  In  the  sequence  of  mission  tasks,  the 
time  problem  occurred.  Since  the  performance  model  Is  computerbased,  the  designer  Is  offered  the 
flexibility  of  quickly  re-running  analyses  of  several  alternative  design  strategies  and  selecting  the 
optlaua  results. 

Another  feature  of  the  analytical  process  Is  the  ability  to  determine  required  crew  size.  The  SWAS  model 
provides  for  Interactions  of  up  to  five  crew  members.  The  designer  Is,  therefore,  provided  the 
opportunity  to  explore  the  crew  size  Impact  of  task  automation  and  ultimately  determine  the  optimum  man- 
machine  mix, 

ELEH2HT  5  -  VALIOATIOW 

A  major  problem  with  analyses  which  accompany  complex  avionics  systems  development  Is  having  confidence  In 
the  analytical  data.  If  a  high  level  of  confidence  1$  achieved,  simulation  and  flight  test  requirements 
can  be  reduced  or,  at  worst,  better  planned.  Bell's  predictive  methodology  has  been  validated  during 
several  design  programs  via  both  man-ln-the-loop  (N-I-L)  simulation  and  Flight  test.  As  Illustrated  1n 
the  following  figures,  extremely  accurate  system  performance  predictions  have  been  achieved. 


2 


System 

Performance 

1 

(Time  Required  ♦ 
Time  Available) 


0 

Ov«r«n  $»9*mnt  1  S«9m«nt  2  I  S^jwum  4  S^giwnt  $  S49m<nt  t 


Mission  Segment 


Figure  10.  Predicted  Versus  Actual  Performance 
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Figure  10  shows  a  coaparlson  of  predicted  versus  actual  systen  perfomance  data  for  six  segaents  of  a 
helicopter  antl-araor  alsslon.  The  systea  perforaance  data  (tiae  required  versus  tiae  available)  was 
generated  analytically,  then  collected  during  H-t-L  slaulatlon  using  six  alsslon  segaents  Identical  to  the 
analytical  segaents.  As  shown,  the  predicted  vs.  actual  results  coapare  quite  closely. 


F  •  Flight  Test:  S  •  SWAS  Model;  APT  •  Pre-Point 


Figure  11.  Predicted  Versus  Flight  Test  Data 


Figure  11  shows  a  comparison  of  predicted  performance  data  and  actual  flight  test  data  for  a  series  of 
tasks  which  evaluated  pilot  time  performance  during  a  nap-of-the-earth  target  acquisition  exercise  (with 
and  without  FLIP  pre-pointing)  while  using  automatic  and  manual  flight  control  system  modes.  As  In  the 
previous  example,  the  predicted  and  actual  performance  data  compare  very  favorably.  It  Is  Important  to 
note  that,  1n  this  example,  the  predicted  time  required  data  Is  identified  as  "equipment”  or  "operator" 
time.  Recall  that  In  the  earlier  analytical  stages,  critical  task  times  are  developed  for  both  operator 
and  equipment  tasks.  The  delineation  of  times  as  shown  Is  the  manifestation  of  that  process.  This  allows 
the  designer  to  more  accurately  examine  the  significance  of  the  man-machine  division  of  labor  for  each 
task  and  assess  the  Impact  of  alternate  automation  strategies.  As  a  side  note,  the  near-linear 
relationship  between  less  system  automation  and  increasing  operator  time  required  depicts  what  might  be 
heurlstically  predicted;  I.e.,  that  operator  workload  Increased  as  automation  decreased. 


Benefits  to  the  Designer 


Results  obtained  from  the  predictive  methodology  process  provide  the  basis  for  several  types  of  decisions 
that  are  Integral  to  the  advanced  avionics  design  process.  Examples  of  the  data  output  and  the  kinds  of 
decisions  that  data  supports  are  shown  in  the  following  table. 


DATA  OUTPUTS 


DECISION  SUPPORTED 


•  Operator  workload  by  mission  segment  •  Determination  of  required  crew  size 

•  Workload  demands  oy  task 


■  Equipment  workload  by  mission  segment  *  Does  equipment  selected/conceptualized  meet  mission 

demands? 

•  What  characteristics  and  capabilities  must  new  equip¬ 
ment  have? 


Detailed  task  time  ratios 
(time  required  vs.  time  available) 


Is  the  man-machine  system  able  to  meet  mission 
requirements? 
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While  helping  the  designer  Hke  eore  *«11d  end  tiaely  systea  configurstlon  decisions  reduces  cost,  aore 
tangible  efficiencies  are  realized  by  enabling  a  reduction  In  engineering  slaulatlon  developaent  and 
experlaental  flight  testing.  Prudent  use  of  the  predictive  aethodology  offers  opportunities  to  reduce  the 
nuaber  of  part-task  developaental  slaulatlons  and  finalize  full  alsslon  slaulatlon  configurations  earlier. 
Part-task  flight  testing  requireaents  can  also  be  reduced.  The  need  for  aanned  soft-aockup  studies  can  be 
ellalnated  In  aany  cases.  All  such  Initiatives  potentially  laprove  design  process  efficiency  and 
ultlaately  reduce  the  acquisition  life  cycle. 
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DISCUSSION 


G.Huat,  UK 

In  addition  to  data  on  the  time  taken  for  the  aircrevw  to  perform  a  task,  simulation  tests  also  produce  data  on  the 
accuracy  >Aith  which  the  result  is  achicveu  and  on  the  difficul  y  experienced  by  the  aircrew  (e.g.,  the  Cooper-Harper 
rating  scale).  Does  the  analytic  model  you  described  produce  similar  data? 

Author’s  Reply 

Yes,  the  methodology  accounts  for  error  rates,  missed  tasks,  restarts,  etc.  Subjective  data,  such  as  Cooper-Harper,  are 
used  to  supplement  quantifiable  results. 


G.Bouche,  GE 

Did  you  develop  a  general  guideline  on  how  busy  the  operator  should  always  be  kept  to  achieve  optimum  performance 
in  critical  situations? 

Author’s  Reply 

No,  a  general  guideline  has  not  been  developed  on  how  busy  the  operaior(s)  should  be  kept.  Optimum  performance  is 
very  difficult  to  define,  because  it  is  based  on  individual  differences  and  is  highly  situational. 


B.H  Jkdams,  UK 

How  do  you  account  for  the  crew  “scare  level”  in  your  analysis  model? 

Author’s  Reply 

It  is  accounted  for  in  term.s  of  ranges  of  predicted  performance.  The  “scare  level"  factor  affects  quantifiable 
performance  in  several  ways  that  can  be  generalized  and  measured,  although  results  arc  not  exact. 


J.Bart,  US 

Can  this  methodology  be  extended  to  account  for  design  for  maintainability  (e.g.,  fault  dctection/isolation-repair) 
requirements  and  battle  damage  repair? 

Author’s  Reply 

Yes,  in  fact,  this  type  of  work  is  under  way  and  has  been  validated. 


IU,Young,  CA 

( 1 )  Determining  crew  size  has,  in  the  pa,st,  been  quite  subjective  and  often  driven  by  a  myriad  of  factors  other  than 
effective  mission  performance  (e.g.,  size,  weight,  etc.).  No  quantitative  data/  models  have  been  used  extensively  in 
the  past  to  aid  in  establishing  crew  size. 

(2)  Intuitively,  I  think  that  single-crew  aircraft  in  combat  is  a  bad  idea  without  “unacceptable"  automation  being 
necessary. 

(3)  Do  you  have  any  direct  data  now  to  indicate  that  a  single-crew  approach  can  be  effective? 

Author’s  Reply 

Yes,  although  our  results  are  limited  to  the  rotary-wing  community  and  combat  helicopter  programs,  i  would  be  glad  to 

discuss  them  with  you. 

Also,  I  tend  to  -gree  with  your  second  comment.  “Acceptable  automation"  is  the  key  phrase. 
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SUMARY 


This  publication  deals  with  the  process  by  which  requirecnents  for  an  avionic  system  are  translated 
into  an  integrated  crewstation  design.  The  Crewstation  Information  Development  System  (CIDS)  has  been 
divided  into  three  phases  of  activity  which  can  be  summarized  in  the  following  paragraphs  and  illustrated 
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FIGURE  I  CREfSTATION  INFORMATION  DEVELOPMENT  SYSTEM 
PHASE  SUMMARY 

Phase  I,  Methodology  Development*  develops  the  Crewstation  Information  Development.  Methodology 
(CIOS)  which  includes  derivation  of  a  comprehensive  set  of  requirements,  requirement  allocation,  and 
information  utilization  assessment. 


Phase  II,  entitled  Crewstation  Development,  focuses  on  deriving  the  most  effective  methods  of 
utilizing  required  crewstation  information  taking  into  consideration  the  impact  of  the  operational 
environment . 


The  final  phase.  Design  Application,  concerns  the  details  of  crewstation  design,  and  the  develop¬ 
ment  of  a  crewstation  information  manager. 

These  three  phases  of  activity  represent  a  systems  engineering  approach  which  incorporates  the 
disciplines  of  hardware  engineering,  software  engineering  and  human  engineering.  The  result  is  a  crew¬ 
station  design  which  addresses  operator  and  mission  requirements  in  a  manner  which  enhances  the  man 
machine  interface. 


PREFACE 

The  complexity  of  projected  battlefield  operations  requires  increasingly  sophisticated  avionics 
systems  and  crewstation  layouts.  The  associated  demands  on  the  operator  have  escalated  to  the  point 
of  taxing  his  ability  to  rapidly  assimilate  critical  information.  Improving  operator  and  system 
effectiveness  mandates  the  development  of  new  Control  and  Display  avionics  and  the  upgrading  of  existing 
aircraft  avionics  in  a  manner  which  results  in  an  Integrated  crewstation.  Systems  are  required  to  handle 
the  vast  amount  of  information  necessary,  and  still  remain  flexible  enough  to  accommodate  future  growth. 
With  today's  technology,  subsystems  tend  to  be  treated  individually  with  the  result  that  a  unified 
integration  of  the  crewstation  suffers.  The  Crewstation  Information  and  Development  System  (CIDS), 
addresses  these  problems  and  provides  the  traceability  and  flexibility  to  evaluate  requirement  changes 
on  a  system  level. 

The  Intent  of  the  CIOS  three  phase  approach  1$  to  develop  an  avionic  system  architecture  and 
crewstation  operation  derived  from  and  respondent  to  crewstation  needs.  Specifically,  through  the 
development  of  a  software  model,  top  level  requir^nts  are  expanded,  refined,  and  singularly  allocated 
to  a  control  or  display  function  in  the  crewstation.  These  allocations  impose  requirements  on  hardware 
and  software  capabilities,  which  in  turn  dictate  a  top  level  tailored  Controls  and  Display  architecture. 

Copyright  1987  ®  The  Boeing  Company,  all  rights  reserved. 
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The  subsequent  development  of  distinctive  display  formats  and  adaptive  crewstation  controls  based  upon 
a  methodical  interactive  approach  provides  a  mission  and  operator  effective  crewstation  design. 


METHODOLOGY  DEVELOPMENT  (PHASE  I) 

In  the  early  stages  of  a  typical  avionics  development  program,  requirements  are  provided  by  the 
user  in  the  form  of  overall  system  performance  allocations  or  desired  subsystem  capabilities.  In  either 
case  the  designer  Is  presented  with  a  multitude  of  subsystem  design  goals  which  may  or  may  not  result 
in  an  overall  satisfactory  system  performance.  In  many  circianstances  the  pilot  becomes  the  de  facto 
system  Integrator  of  the  various  subsyst^n  operations  with  the  result  that  mission  effectiveness  suffers 
or  workload  Increases.  Therefore,  the  question  becomes  "How  are  requirements  integrated  Into  the  crew> 
station  In  a  manner  which  increases  mission  effectiveness  and  enhances  operator  workload?"  This  problem 
actually  contains  two  distinct  parts:  1)  How  can  the  crewstation  oesigner  incorporate  all  the  various 
subsystem  requirements  in  an  Integrated  manner;  and  2)  assuming  Item  one  can  be  accomplished,  what  is 
the  best  way  to  present  information  and  provide  system  control? 

Phase  I  activity  describes  the  process  by  «Hi1ch  questions  one  and  two  above  are  answered.  The 
CIOS  Methodology  Development  as  shown  In  Figure  2  Is  a  result  of  this  process.  Representative  outputs 
of  this  methodology  will  be  presented  in  Phase  II  after  the  Crewstation  Information  Development  System 
has  been  discussed.  The  Methodology  Development  discussion  will  Incorporate  the  following  major  topics: 
Operational  Requirements;  System  Oesigner  Inputs;  Information  Assessment;  and  Information  Assessment 
Implementation. 


WroWUTlOH  ASSEfflMENT 


o  HOV  TO  DBPUT  INFOBUTION 
o  HOf  TO  aMfTBOt  STSTQIS 

FIGURE  2  PHASE  I  CIDS  METHODOLOGY  DEVELOPMENT 


OPERATIONAL  REQUIREICNTS 

With  reference  to  Figure  2,  requirements  are  provided  in  the  form  of  overall  system  performance 
and  desired  capabilities  for  a  given  operational  environment.  These  requirements  are  translated  into 
system  attributes  with  the  appropriate  traceability  to  source  documents.  This  process  is  the  means 
by  which  overall  mission  requirements  (which  reflect  the  projected  threat  environment  and  enemy 
capabilities)  are  allocated  to  system  operation  functions. 

SYSTEM  DESIGNER  INPlfH 

Once  this  set  of  operational  requirements  Is  compiled,  the  system  designer  is  able  to  expand  and 
modify  it  to  account  for  functional  requirements  not  directly  stated  by  the  user.  This  activity  can 
be  seen  in  Steps  1  and  2  of  OESIGNER  INPUTS  In  Figure  2.  These  requirements  supply  the  details  of  system 
operation  and  provide  the  framework  by  which  subsystems  Interact  in  the  accomplishment  of  overall  system 
objectives.  The  allocation  of  requirements  to  subsystems,  Step  3,  is  the  process  by  which  all 
requirements,  whether  directly  stated  or  derived,  are  assigned  to  functional  areas  of  the  system 
architecture.  This  activity  is  particularly  important  In  that  it  performs  several  major  functions. 
First  of  all,  it  identifies  where  requirements  will  be  performed.  T‘'is  simplifies  the  task  of  identifying 
multiple  uses  of  conmon  information,  and  eliminates  duplication  of  sources.  Additionally,  the  impact 
of  one  subsystem’s  requirements  on  another  are  readily  seen.  Next,  the  allocation  of  requirements 
determines  to  a  large  extent,  the  interfaces  required  between  subsystems.  These  interfaces  begin  to 
identify  control  and  display  functions  needed  in  the  crewstation.  Finally,  this  activity  supports  the 
definition  of  overall  system  operation,  or  what  the  roles  of  mission  and  system  management  are  in  the 
accomplishment  of  mission  objectives  and  system  operation. 


These  first  three  steps  as  described  above  are  the  means  by  which  operator  requirements  drive  the 
avionics  architecture  at  the  initial  stages  of  system  development.  Allocation  of  requirements  to  specific 


subsystems  identifies  needed  hardware  and  software  capabilities.  These  capabilities,  will  be  reflected 
in  the  total  avionic  system  architecture,  the  associated  hardware  elements,  and  the  software  processing. 
The  ultimate  target  is  a  system  initially  aimed  at  and  ultimately  tailored  to  improved  man-machine 
operation. 

The  activities  accomplished  to  this  point  provide  the  ground  work  for  the  major  thrust  of  the 
Crewstatlon  Information  Development  System.  The  next  task  Is  the  assessment  of  crewstatlon  Information 
for  the  purpose  of  determining  how  best  to  control  or  display  it.  This  process  Is  accomplished  by 
critically  evaluating  each  control  and  or  display  requirement  and  suggesting  a  design  implementation. 
Steps  1-3  of  Figure  2  facilitate  the  Identification  of  those  requirements  which  either  must  be  controlled 
by  the  operator,  or  displayed  to  him.  However,  these  same  steps  that  allowed  the  assessment  of 
crewstatlon  Information,  also  have  had  a  direct  Impact  on  the  overall  system  architecture. 

INFORMATION  ASSESSMENT 

Information  assessment  takes  the  top  level,  derived,  and  lower  level  requirements  and  prioritizes 
them  to  arrive  at  an  optimum  Implementation  in  the  crewstation.  This  is  accomplished  by  performing 
three  tasks  which  are:  the  determination  of  when  during  the  mission  specific  Information  must  be 
controlled  or  displayed;  the  assessment  of  the  critical  nature  of  the  information  as  It  relates  to  overall 
system  operation;  and  the  assessment  of  the  criticality  of  the  information  itself  as  it  relates  to  the 
accomplishment  of  goals  during  specific  phases  of  the  mission.  Once  these  tasks  are  accomplished  for 
all  the  requirements,  of  all  the  subsystems,  it  is  possible  to  assign  specific  control  devices  and  display 
types  to  the  crewstation.  This  process  can  be  seen  in  Figure  3,  Information  Assessment  Implementation. 
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INFORWTIOM  ASSESSMENT  IMPLENENTATION 

Steps  1  through  5  of  the  Information  Assessment  Implementation  deal  with  functions  requiring 
crewstation  controls  on  the  left  of  the  figure  and  crewstation  displays  on  the  right  of  the  figure. 
The  circled  numbers  indicate  the  sequence  ef  activity,  and  the  asterisks  specify  those  areas  where  inputs 
from  the  crewstatlon  designer  are  required.  As  stated  earlier,  the  first  step  of  the  crewstatlon 
requirement  implementation  is  the  determination  of  when  during  the  mission  segment  previously  identified 
control  and  or  display  functions  are  needed.  For  the  purposes  of  this  paper  we  shall  consider  a  combat 
mission  with  the  following  mission  segments: 

0  Pre-take-off  o  Take-off  o  Enroute  o  A1r-to-a1r/air-to-ground 

0  Egress  o  Landing  o  Shut  down 

In  addition  to  determining  when  to  display  or  control  information,  the  criticality  of  that 
Information  must  also  be  assessed.  Assessing  the  criticality  of  crewstatlon  information  is  a  two  part 
task  which  corresponds  to  Steps  2  and  3  of  the  Information  Assessment  Implementation  (Figure  3).  Step 
2  involves  detennining  if  the  function  is  flight,  survival,  mission,  or  mission  enhancement  critical. 
The  definition  of  these  criticalities  is  stated  below  on  the  next  page  and  roughly  equates  to  that  used 
in  HIL-STD-882,  System  Safety  Program  Requirements. 
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DISPLAY  TYPES  CONTROL  DEVICES 

0  Alphanumerics  (A)  o  Dedicated  hands  on  control  (DHC) 

0  Graphics  (G)  o  Programmable  display  push  button  (PDP) 

0  Symbology  (S)  o  Dedicated  Control  (DCL) 

0  Artificial  voice  response  (V)  o  Voice  (VRR) 

0  Touch  screen/bezel  (1-06) 


Each  of  these  ways  of  displaying  Information  to  the  crewmember  or  controlling  system  functions  has  Its 
unique  numerical  value  when  evaluated  according  to  the  critical  parameters.  A  summary  of  this  evaluation 
can  be  seen  in  Table  1.  By  totaling  the  individual  ratings  of  symbology,  voice  reponse,  graphics,  and 
alphanumerics.  It  Is  possible  to  numerically  rank  display  types.  This  numerical  ranking  suggests  that 
certain  ways  of  displaying  certain  types  of  information  are  more  appropriate  than  others.  For  example, 
symbology  ranks  high  (numerical  value  5)  for  time  criticality  (TCRIT)  and  comprehension  (CMPH).  However, 
it  is  not  as  suitable  where  complexity  is  concerned  (CMPX  value  of  4).  Alphanumeric  on  the  other  hand 
has  a  high  value  for  complexity,  but  low  values  for  time  criticality  and  comprehension.  Using  this 
criteria  it  is  possible  to  compare  the  numerical  ranking  of  the  crewstatlon  requirements  to  that  of 
display  media  in  order  to  suggest  the  most  appropriate  control  or  display  means.  The  problem  with  this 
direct  comparison  Is  that  it  does  not  account  for  the  Importance  of  flight,  survival,  mission,  and  mission 
enhancement  criticalities  during  specific  mission  segments.  To  account  for  these  Influences  on  control 
and  display  implementation,  weight  factors  which  correspond  to  the  mission  segment  and  flight  criticality 
of  the  requirement  are  factored  into  the  numerical  value  of  its  assigned  critical  parameters. 


TABLE  1  DISPLAY  MEDIA/CONTROL  DEVICE  CRITICALITY 


These  weight  factors  are  derived  from  the  following  three  technical  papers:  ’’Artifical  Intel  1  igence 
Approaches  in  Intelligent  Helicopter  Automation  for  Nap-of-the-Earth  Missions;”  "Flight  Management  for 
Air-to-Surface  Weapon  Delivery;"  and  "Automation  in  Combat  Aircraft."  In  all  of  these  papers  experts 
were  asked  to  evaluate  specific  mission  segments  and  functions  that  have  the  largest  impact  on  mission 
objectives.  The  summation  of  the  results  of  these  papers  is  illustrated  1;,  Table  2.  Interestingly 
enough,  the  importance  of  specific  mission  segments  in  the  accomplishment  of  flight,  survival  and  mission 
objectives  does  not  appreciably  vary  from  fixed  winq  to  rotorv  wino  aircraft  missions. 

_ TABLE  2  WEIGHT  FACTORS _ 


The  final  aspect  of  PhaU  I  Methodology  Development  concerns  the  method  by  which  crewstation  require¬ 
ments  are  allocated  to  control  devices  or  display  information  types  (symbology,  alphanumerics,  graphics 
etc.).  Essentially,  what  this  entails  is  matching  the  numerical  total  of  a  critically  assessed 
requirement  biased  by  an  appropriate  weight  factor  (Table  2)  against  a  prioritized  list  of  control  devices 
or  display  information  types  (Table  1). 


For  example,  assume  that  a  display  requirement  has  a  total  of  17  when  evaluated  according  to  the 
five  critical  parameters  discussed  earlier  (TCRIT,  CON,  CMPX,  FREQ, 'and  CMPH).  Also,  assume  that  the 
display  requirement  is  survival  critical  (SUR)  and  is  displayed  during  an  enroute  mission  segment. 
The  weight  factor  for  this  display  requirement  is  0.7  (Table  2).  If  we  multiply  17  times  0.7,  the  product 
Is  11.9  which  does  not  Immediately  suggest  a  display  type  when  compared  to  the  TOTALS  of  Table  1.  To 
resolve  this  dilemma,  a  range  of  values  which  would  provide  a  suggested  control  device  or  display  type 
when  compared  to  a  requirement's  weighted  critical  assessment  was  developed.  The  results  of  this 
development  can  be  seen  in  Table  3,  Display  Type  Allocation  Values. 


0  Flight  Critical  (FIT)  -  a  control  action  or  display  function  which  if  lost  or  degraded 
would  seriously  impair  or  negate  the  pilot's  ability  to  fly  the  aircraft. 

0  Survival  Critical  (SUR)  -  a  control  action  or  display  function  which  directly  or 
indirectly  affects  the  ability  of  the  aircraft  to  survive  in  a  hostile  environment. 

0  Mission  Critical  (MSN)  -  a  control  action  or  display  function  which  affects  the 
performance  of  mission  objectives. 

0  Mission  Enhancement  (MSNE)  -  control  actions  or  display  functions  which  if  lost  would 

not  automatically  nullify  the  accomplishment  of  mission  objectives,  but  may  necessitate  degraded 
mode  operation  or  work  around  implementation. 

The  final  task  of  criticality  assessment  involves  the  evaluation  of  crewstation  requirem-'nts  against 
five  parameters  for  display  functions,  four  of  which  are  also  used  for  control  functions.  These 
parameters  are  used  to  determine  the  criticality  of  a  control  action  or  display  function  as  it  relates 
to  the  accomplishment  of  mission  segment  tasks  previously  allocated.  These  parameters  are  defined 
below,  the  first  four  of  which  pertain  to  both  control  and  display  assessment,  and  the  final  one  which 
deals  exclusively  with  display  assessment.  A  rating  scale  follows  each  critical  parameter,  to  provide 
a  means  of  quantitatively  rating  each  crewstation  requirement. 


Time  Criticality  (TCRIT)  -  the  requirement 
for  control  actions  or  display  information 
to  be  immediately  available  during  a  mission 
segment. 


1  -  Improbable 


Concurrency  (CON)  -  the  requirement 
for  control  functions  or  display  inform¬ 
ation  to  be  available  concurrently 
due  to  mission  segment  demands.  The 
higher  the  incidence  of  concurrency 
the  greater  the  need  for  immediate  access. 

1  -  Improbable 


3  -  Occasional  3  -  Occasional 

4  -  Probable  4  -  Probable 

5  -  Frequent  5  .  Frequent 

0  Complexity  (CMPX)  -  the  degree  of  difficulty  in  o  Frequency  (FREQ)  •  the  number  of  times 
performing  a  control  function  or  in  assimilating  during  a  particular  mission  segment 

display  information.  that  control  actions  or  display  inform¬ 

ation  will  be  required. 

1  -  Elementary  1  _  improbable 

2  -  Simple  2  -  Remote 

3  -  Difficult  3  -  Occasional 

4  -  Complex  4  -  Probable 

5  -  Very  complex  5  -  Frequently 

0  Comprehension  (CMPH)  -  the  difficulty  of  specific  display  information  to  be  understood,  which 
is  to  a  large  degree  dependent  on  the  required  accuracy  of  the  information.  For  example,  b-.ik 
angle  may  not  require  any  great  degree  of  precision  whereas  final  approach  airspeed  does. 


3  -  Occasional 

4  -  Probable 

5  -  Frequently 


2  -  Simple 

3  -  Moderate  comprehension  difficulty 

4  -  Difficult  to  comprehend 

5  -  Most  difficult  to  comprehend 


Once  all  of  the  crewstation  requirements  have  been  assigned  to  mission  segments  an,'  prioritized 

according  the  preceeding  definitions,  the  control  device  and  display  type  can  be  selected  These  fi-'t 

three  steps  can  be  accomplished  by  the  crewstation  designer  or  by  the  user.  If  the  latter  approach 
is  used  several  benefits  will  occur.  First  of  all.  the  inclusion  of  the  user  at  this  early  stage  of 
deve  opment  will  provide  authenticity  as  well  as  valuable  operational  inputs  which  may  not  be  reLily 
available  to  the  crewstation  designer.  Also  by  allowing  the  operational  user  the  opportunity  to  evaluate 
the  importance  of  control  actions  and  display  information.  It  is  possible  to  tailor  the  crewstation 
to  various  user  preferences. 

b  inputs  for  the  Crewstation  Information  Development  System  completed,  the  process 

by  which  control  devices  and  display  types  are  selected  can  be  discussed.  This  process  involves  the 

several  display  types  according  to  the  some  critical  parameters  (TCRIT,  CON,  CMPX,  FRED 
and  CMPH)  discussed  previously.  The  rating  of  these  display  types  can  then  be  matched  against  the  ini 
dividual  crewstation  requirements  to  determine  a  design  implementation.  The  display  types  and  control 
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The  derivation  of  the  limits  for  each  criticality  can  be  described  in  four  steps:  1)  upper  limit; 
2)  lower  limit;  3)  upper  intermediate  limit;  and  4)  lower  intermediate  limit.  We  will  use  flight 
criticality  of  display  types  as  an  example. 

Step  1  deals  with  the  upper  limit  of  flight  criticality,  22.50.  Since  there  are  five  possible 
information  assessment  categories  (time,  concurrency,  complexity,  frequency,  and  comprehension), 
and  the  highest  value  for  each  is  5,  the  highest  total  of  these  is  25.  The  highest  weight 
factor  for  flight  critical  is  0.9  (Table  2).  Therefore,  the  highest  value  that  a  flight 
critical  display  requirement  could  be  is  25  times  0.9,  or  22.5. 

The  derivation  of  the  lower  limit  of  flight  criticality.  Step  2,  follows  the  same  reasoning 
as  Step  1.  The  lowest  possible  total  value  for  the  information  assessment  is  5.  The  lowest 
possible  flight  critical  weight  factor  is  0.2.  Therefore,  the  lower  limit  is  1.00. 

Step  3  deals  with  the  derivation  of  intermediate  limits.  Symbology  has  the  largest  total 
value  of  the  display  types  listed  in  Table  1.  If  we  multiply  this  number,  22,  times  the  average 
weight  factor  for  flight  critical,  0.58,  we  obtain  12.76. 

The  required  range  for  flight  critical  symbology  therefore  is  12.76  to  22.5.  The  upper  limit 
for  the  next  highest  display  type.  Step  4,  (voice,  total  =  19,  Table  1)  is  O.Pl  below  the 
lower  range  for  symbology  or  12.75.  Taking  the  average  weight  factor  for  flight  critical 
(0.58),  times  the  total  fer  voice  (19)  gives  the  lower  range  for  voice,  11.02.  Therefore, 
the  lange  for  voice  is  11,02-12.75. 


TABLE  3  DEPUY  TYPE  ALLOCATION  VALUES 


1  DEPUY 

UEDIUU 

FLIGHT  CRITICAL 
(FLT) 

SURVIVAL  CRITICAL 
(SUR) 

Mission  critical  (usn)! 

lUEBION  ENHANCEMENT  j 
!  IMSNEl 

1  SYMBOLOGY  (S) 

22  S0  -  12.76 

20.00-  12.32 

17.50  -  9.46 

1  VOICE  {V)  1 

12  75  -  11.02 

12.31  -  10.64 

9.45  -  8.17 

[  GRAPHICS  (G) 

11.01  -  8.70 

10.63  -  8.40 

8.16  -  6.45 

ALPHA  (A)  ! 

8  69  -  8.12  j 

8.39  -  7.84 

6  44  -  6.02 

1  OPTION  (OPT) 

8.11  -  1.00 

7.83  -  100 

6.01  -  ^  ; 

TABLE  4  CONTROL  DEVICE  ALLOCATION  VALUES 


CONTROL 

DEVICE 

1  FLIGHT  CRITICAL 
i  (FLT) 

survival  CRITICAL 

(SUR  __  i  (usNE) 

DEDICATED  HANDS-ON  CONTROL  (DHC) 

T  18.00  -  9.^ 

16.00  -  8,91 

1  14,X  -  6.86 

VOICE  (VRR) 

j  9.25  -  8.11 

8.90  -  7.80 

1  6.85  -  6.01 

PROGRAMMABLE  DEPUY  PUSHBUTTON  (PDP) 

i  8.10  -  6  .37 

1  7,79  -  6,13 

6,X  -  4,72 

TOUCH  SCREEN  (FOG) 

:  6.36  -  5.79 

r  6.12  -  5.5'’ 

'  471  -  4,29 

DEDICATED  CONTROL  (XL) 

1  5.78  -  .80  1 

5  56  -  80 

]'  4.28  ,40 

Referring  back  to  the  example  described  earlier,  a  survival  critical  display  requirement  with  a 
total  of  17,  a  weight  factor  of  0.7,  and  a  product  of  11.9,  would  result  in  the  selection  of  voice  as 
the  optimum  display  type  (see  Tab'e  3).  Table  4  provides  the  control  device  allocation  values.  The 
derivation  of  these  values  is  identical  to  that  of  display  types. 

The  development  of  the  CIOS  Methodology  which  facilitates  the  assessment  of  crewstation  requirements, 
completes  the  activity  of  Phase  I.  Phase  II,  Crewstation  Development  discusses  the  results  of  methodology 
implementation  and  the  beginnings  of  a  crewstation  information  management  function. 


CREWSTATION  DEVELOPMEWr  (PHASE  II) 

The  second  phase  of  the  Crewstation  Information  and  Development  System  deals  with:  data  base 
management;  information  assessment  results;  display  information  prioritization;  and  crewstation  management 
development.  T’,e  major  emphasis  of  the  second  phase,  is  the  discussion  of  the  results  obtained  through 
the  implementation  of  the  CiDS  Methodology  developed  in  Phase  1.  The  discussion  of  these  results  will 
be  conducted  in  six  parts.  These  parts  include:  source  requirements;  functional  requirements; 
requirement  allocations;  detailed  allocdtion;  information  assessment  values;  and  information  allocation. 
Methods  of  prioritizing  information  in  the  crewstation  will  be  discussed  w.th  the  goal  of  providing 
a  flexible  method  of  dealing  with  a  dynamic  operational  environment.  Finally,  using  the  results  of 
information  assessment,  we  will  briefly  discuss  the  initial  development  of  a  crewstation  information 
manager.  However,  before  the  methodology  results  are  presented  a  brief  comment  concerning  data  base 
management  is  appropriate. 

DATA  BASE  NANAGEMENT 

When  CIOS  was  initially  conceived,  the  size,  complexity  and  intricacies  of  the  data  base  were  not 
imagined.  What  began  as  an  effort  to  develop  an  integrated  crewstation  design  with  an  equivalent  data 
base,  became  an  entire  avionic  system  with  its  associated  data  bases.  This  resulted  from  the  desire 
to  develop  a  realistic  design  effort  which  could,  at  some  point,  become  a  gene^'ic  model  for  a  system 
engineer  tool.  The  data  bar's  expanded  to  include  total  system  requirements,  at.  as  this  happened  the 
need  to  develop  a  common  data  base  which  Included  all  thp  significant  activities  of  the  CIDS  Methodology 
became  apparent.  The  software  used  throughout  Phase  I  and  II  was  PC  FOCUS  which  is  a  comprehensive 
itiformatioii  control  system  with  some  arithmetic  applications  and  a  limited  graphics  capability.  In 
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Phase  I  of  CIDS,  data  was  processed  for  each  step  of  the  development  methodology.  This  was  accomplished 
by  creating  programs  which  retrieved  required  data  from  a  preceeding  step  of  methodology  development, 
and  inputting  new  data  as  required.  This  process  became  somewhat  limited,  in  that  data  generated  in 
one  step  could  not  automatically  be  used  in  a  preceeding  step  if  the  need  arose.  This  process  also 
consumed  a  lot  of  overhead  (duplicated  data  files  and  programs)  and  added  to  an  already  large  data  base. 
In  short  the  need  for  a  common  data  base  has  proven  to  be  an  important  requirement  which  in  future 
applications  will  be  incorporated. 


INFORMATION  ASSESSMENT  RESULTS 

In  order  to  present  the  results  of  CIDS  in  a  logical  manner,  we  shall  follow  the  sequence  of  activity 
used  in  the  discussion  of  the  CIDS  Methodology.  Representative  data  will  be  presented  in  the  form  of 
Tables,  and  for  the  purpose  of  clarity  we  will  deal  with  one  subsystem  of  an  avionic  architecture. 
Armament  Control . 

SOURCE/FUNCTIONAL  REQUIREMENTS 

Table  5,  Source/Functional  Requirement,  shows  requirements  which  as  a  starting  point  have  initially 
been  allocated  to  the  Armament  Control  subsystem.  At  this  point,  the  assignment  of  a  requirement  to 
a  subsystem  is  somewhat  arbitrary  but  does  provide  an  organizational  tool  for  the  disposition  of  all 
user  stated  capabilities.  The  first  column  of  Table  5  shows  the  requirement  numbers  assigned  to  each 
requirement.  These  numbers  are  the  means  by  which  requirements  are  traced  to  source  documents.  In 
addition,  requirements  which  are  not  directly  stated  by  the  user,  and  those  requirements  which  are  needed 
to  support  subsystem  functions,  are  also  documented  to  provide  traceability. 


TABLE  5  SOURCE/FUNCnONAL  REQUIREUENTS 
ARMlUm  CONTROL 


REQ 

NO 

REQUIREMENT 

DERIVED 

REQMT 

STATED 

REQMT 

FUNCriONAl 

REQMT 

.  -moo^ 

.  aOLQO- 

.aOLQ3_ 

.  _XLQ4.. 

.  aoLoe  _ 

.  -302.00  _ 

.  -304.00  _ 

.  -304.01- 
.  -304.02- 

iUN-'AUTQ.CUEIKCU'TRACKIN&  QF-VEHICLES.Aiill  AIECRAFL 
RgQtrfWm  FUNCTIONS  _  _ 

DERIVED 

L,  RAKT.E  FfNDMC  „  ... . . 

DESIGNATION 

.  J)ERiyED. 

OERlVRn 

J)ERiyEIi, 

LAUNCHIliG4MISSIliS.  ROCKETS). 

EIRINC4GUK)- 

DERIVED- 

STORES  JETEEDN  _ 

DERlVEn 

.2DDJD.6 

EUNCriONAl 

EUNCTJDNAI 

Balletic  cai£Ulations _ _  _ 

.  DERIVED- 

.  DETERMINE-CCIE  ..  - _ _  _  _  _ 

Requirement  numbers,  in  groups  of  100,  are  allocated  to  each  subsystem  so  that  the  assignment  of 
numbers  to  requirements  provides  an  initial  subsystem  allocation.  For  example.  Armament  Control  is 
assigned  the  number  block  from  300.00  to  399.00.  Therefore,  a  requirement  stated  by  the  user  or  derived 
from  the  designer,  which  Initially  appears  to  fit  in  the  Armament  Control  subsystem  would  be  given  a 
number  from  300.00  to  399.00.  The  decimal  places  to  the  right  of  the  decimal  indicate  top  level  and 
lower  level  requirements.  Two  zeros  indicate  a  top  level  requirement,  and  XXX. 01  thru  XXX. 99  indicate 
lower  level  requirements  related  to  the  top  requirement.  It  is  important  to  note  that  this  system 
provides  the  capability  to  assess  the  impact  of  requirement  changes,  determine  degraded  mode  operation, 
and  indicate  how  requirements  have  been  satisfied  in  the  design.  These  capabilities  are  possible  due 
to  the  fact  that,  throughout  the  CIOS  Methodology,  a  requirement  retains  its  originally  assigned  number 
with  more  decimal  places  added  to  the  right  as  the  requirement  is  expanded. 

REQUIREMENT  ALLOCATION 

Once  requirements  have  been  assigned  a  number  and  initially  allocated  to  subsystems,  they  are  evalu¬ 
ated  as  to  how  they  interact  with  all  the  other  subsystems.  Initially  this  consists  of  determining 
where  the  performance  of  the  requirement  in  question  is  accomplished.  Referring  to  Table  6,  a  "P"  under 
the  appropriate  subsystem  column  indicates  that  this  subsystem  is  the  source  of  the  required  information. 

An  "0"  followed  by  a  letter  corresponding  to  a  subsystem,  indicates  an  output  from  that  column  to  the 

subsystem  indicated  by  the  letter.  For  example,  requirement  number  301.04  shows  an  "OW"  in  the  CPT 
(cockpit)  column.  This  means  that  there  is  an  output  from  the  cockpit  to  the  armament  subsystem  (W). 
In  addition,  the  accomplishment  of  this  requirement  is  performed  In  the  armament  subsystem,  indicated 

by  a  "P"  in  the  "ARM"  column.  The  last  column  of  the  table  (C4D)  shows  that  requirement  301.04  has 

both  a  control  function  and  a  display  requirement  indicated  by  "C/D".  The  identification  of  these  control 
functions  and  display  requirements  provides  the  data  required  for  information  assessment  and  information 
allocation  steps  of  the  CIOS  process. 


TABLE  6  REQUlREMDrr  ALLXAT10N  AND  INTERFACE 
ARMAMENT  CONTROL 


REQ 

NO 

REQUIREMENT 

MSN 

MGT 

(Ml 

STS 

MGT 

(S) 

COMN 

(C) 

NAT 

(N) 

FIT 

CT 

(F) 

ARM 

(W) 

ASE 

(A) 

3  §3 

CPT 

(H) 

NVP 

(V) 

P 

R 

0 

C 

(K) 

C&D 

300.00- 

.  -MAS/AUTD  CUEINC/JRACKINC  DE  SEHlCliS.  AND  ABCHAFI  . 
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Once  all  the  requirements  have  been  allocated  to  a  subsystem,  and  an  initial  cut  at  the  subsystem 
interfaces  has  occurred,  a  sort  of  all  the  inputs,  outputs,  and  assigned  requirements  for  a  subsystem 
is  accomplished.  The  assembled  data  from  this  computer  sort  contains  all  the  information  concerning 
the  functions  performed  by  that  subsystem,  and  the  information  required  from  other  subsystems  to  support 
them.  This  data  provides  the  system  designer  the  ability  to  verity  proper  subsystem  to  subsystem 
communication.  In  addition,  support  data  required  by  one  subsystem  from  another  is  immediately  indicated 
in  the  sorted  report  data  of  both  affected  subsystems.  This  is  important  due  to  the  fact  that  subsystem 
design  is  usually  allocated  to  separate  design  groups,  and  as  such  the  needs  of  one  group  are  not  always 
efficiently  comirunicated  to  another. 

DETAILED  ALLOCATION 

The  allocation  process,  which  was  initiated  with  the  allocation  of  requirements  to  subsystems, 
continues  in  this  next  area  with  the  allocation  of  requirements  to  software  modules  and  hardware  line 
replaceable  units  (LRUs).  In  addition,  unit  values,  frequency  requirements,  accuracies,  and  range  data 
are  developed.  This  information  is  illustrated  in  Table  7,  and  provides  additional  requirement  detail 
to  assure  acceptable  performance.  Through  this  activity  and  that  of  the  preceeding  section,  the 
crewstation  requirements  make  their  impact  on  the  other  subsystems  and  on  the  total  avionic  architecture. 


TABLE  7  DETAILED  INEORUATION  ALLOCATION 
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INFORHATION  ASSESSMENT  VALUES 

With  the  assignment  of  all  subsystem  requirements  to  either  a  "C",  "D"  or  both  “CAD"  it  is  possible 
to  assess  control  and  display  functions  separately  for  the  purpose  of  assigning  criticalities.  The 
assignment  of  these  values  can  be  seen  in  Table  8.  Display  Information  Assessment  Values,  and  Table 
9,  Control  Assessment  Values. 
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yes-up>  2  -  head-up,  eyes-down,  3  -  head  doum,  and  1/2  either  1  or  2)  and  Is  based  upon  the  flight 
criticality  of  the  display  requirement.  The  WHEN  column  provides  information  about  when  to  display 
information  to  the  crewmember.  The  choices  available  are:  CON  continuously;  REQ  -•  on  request;  M-C 
-  mode  dependent  continuously;  and  M-R  -  mode  dependent  on  request.  The  derivation  of  these  assignmpnts 
is  based  on  the  numerical  total  of  time  criticality  (TCRIT),  freq'JC.?:^  and  concurrency  (CON). 

T^-:  :-:-.gc  conttar*  (rON)  Is  14-16,  for  mooe  constant  (M-C)  is  9-13,  and  for  mode  on  request  in  1-8. 

Table  9,  Control  Assessment  Values,  provides  similar  information  as  that  of  Table  8  with  the 
exception  that  "when”  and  "where"  are  not  directly  addressed  but  are  a  function  of  the  control  device 
used.  It  is  significant  to  note  that  the  options  supplied  for  control  devices  and  display  types  are 
not  sufficiently  reduced  to  allow  a  definitive  choice.  However,  using  the  information  developed  in 
Tables  3  and  4  the  optimum  choice  for  both  display  type  and  control  device  can  be  made.  The  results 
of  employing  Tables  3  and  4  to  suggest  a  control  device  or  display  type  can  be  seen  in  Tables  10  and 
11.  The  display  type  and  control  device  suggestion  are  accomplished  by  comparing  the  product  obtained 
from  the  total  of  the  information  criticalities  and  a  weight  factor  with  the  values  of  Tables  3  and 
4.  The  result  of  this  process  is  shown  under  the  "CHOICE"  column  of  Table  10,  and  the  "1ST  PIK"  column 
of  Table  11.  Additionally  provided  is  a  "2N0  PIK"  for  control  device  to  provide  an  alternate  means 
of  crewstation  control.  Both  Tables  show  the  information  critical  parameter  which  had  the  greatest 
impact  on  the  display  type  or  control  device  selection.  The  significance  of  the  data  in  Tables  10  and 
11  is  that  display  formats  can  be  developed  for  specific  areas  (head-up  eyes-out,  head-up  eyes-down) 
of  the  crewstation,  and  for  specific  times  during  the  mission  (take-off,  enroute,  etc.). 


table  10  DlSPUr  WEDU  ALLOCATION 
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during  contour  flight.  The  amount  of  information  displayed  has  been  significantly  reduced,  due  to  the 
fact  that  information  can  be  selectively  prioritized. 
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The  impact  of  this  process  is,  with  the  user  evaluating  control  and  display  requirements  according 
to  the  critical  parameters  discussed  in  this  paper,  the  crewstation  can  be  tailored  to  individual  needs. 
In  addition  the  specific  information  that  is  shown,  and  how  it  is  shown,  can  become  a  dynamic  function 
of  the  operational  environment. 

With  the  discussion  of  display  information  prioritization  completed,  the  description  of  Phase  II 
activity  is  complete.  Phase  II  presented  the  results  of  the  CIDS  Methodology  Implementation  in  the 
form  of  representative  outputs  of  the  Armament  Control  subsystem.  Phase  III  will  discuss  the  next  steps 
in  the  design  implementation  of  the  CIDS  results. 


DESIGN  APPLICATION  (PHASE  III) 

Phase  III  deals  with  the  activity  which  has  been  initiated,  but  which  at  this  point  has  not  been 
completed.  The  major  tasks  of  this  phase  include:  display  format  refinement;  crewstation  design,  which 
includes  detailed  display  formats  along  with  control  device  allocation;  crewstation  information  management 
development;  and  design  evaluation.  The  first  three  tasks  are  in  various  stages  of  development,  and 
that  development  will  be  briefly  discussed.  The  final  task,  design  evaluation,  will  include  a  review 
of  the  criticality  assessment  values  and  the  implementation  of  the  CIOS  Methodology  into  a  crewstation 
mock-up. 

DISPLAY  FORMAT  REFINEMENT 

The  process  by  which  display  information  is  allocated  to  specific  areas  of  the  crewstation  was 
discussed  in  Phaso  II.  The  intent  of  this  allocation  was  to  generate  a  group  of  information  display 
requirements  for  a  specific  crewstation  location,  and  of  specific  display  types  (symbology,  graphics, 
and  alphanumerics),  for  the  purpose  of  developing  display  formats.  This  process  has  been  initiated 
with  varying  degrees  of  success.  The  major  problem  encountered  was  that  the  display  information 
requirements  were  not  sufficiently  grouped  to  allow  the  formation  of  functional  display  formats.  In 
other  words,  information  which  would  typically  be  associated  with  system  mode  control  and  status,  primary 
operation,  or  secondary  operation  did  not  readily  fall  out  of  the  CIDS  Methodology  in  order  to  facilitate 
functional  grouping  of  display  information.  This  functional  allocation  is  in  progress.  Once  all  of 
the  subsystem  display  information  has  been  allocated  to  functional  display  formats,  the  formats  will 
be  developed. 

CREWSTATION  DESIGN 

The  second  aspect  of  Phase  III  is  the  detailed  design  of  the  crewstation  itself.  The  development 
of  the  display  formats,  along  with  a  composite  list  of  all  the  dedicated  and  non-dedicated  crewstation 
controls,  will  enable  the  physical  layout  of  the  crewstation.  In  addition,  by  knowing  what  information 
is  to  displayed  at  what  time  and  where,  it  is  possible  to  determine  the  required  number  of  displays 
and  their  location.  This  activity  equates  to  the  development  of  a  physical  crewstation  which  is  the 
result  of  a  methodical  integrated  approach. 

CREWSTATION  INFORMATION 

The  final  area  of  Phase  III  activity,  which  is  presently  in  work,  is  the  development  of  a  crewstation 
information  manager.  The  intent  of  this  effort  is  to  develop  a  crewstation  manager  which  takes  the 
basic  work  done  in  CIOS  and  refines  the  prioritization  of  display  information.  To  facilitate  this  effort 
a  generalized  "expert  system"  approach  is  being  employed.  Some  of  the  goals  of  this  activity  are: 
demonstration  of  a  prototype  architecture  concept;  development  of  flexible  formats  for  crewstation 
displays;  development  a  scenario  driver;  development  a  graphics  interface  to  a  crewstation  mockup;  and 
demonstration  of  a  working  model  within  12  months. 

To  accomplish  these  objectives  a  scenario  was  developed  which  provides  a  realistic,  action  packed 
description  of  a  combat  mission,  which  initially  encompasses  a  2  to  3  minute  time  frame.  This  scenario 
is  intended  to  require  "intelligence”  either  supplied  by  the  crewnember  of  Inherent  in  the  software 
to  provide  task  essential  information.  This  "Intelligence"  necessitates  the  development  of  a  variety 
of  objects  and  rules.  Work  has  begun  to  prepare  a  story  board  which  will  provide  a  description  of  the 
internal  and  external  situation  for  time  slices  of  the  scenario.  As  a  result  of  the  story  board  activity, 
the  data  required  for  the  scenario  from  the  avionic  systems  will  be  identified  and  corresponding  objects, 
attributes,  and  icons  will  be  developed.  Once  this  information  is  known  (ie.  objects  which  must  be 
reasoned  about),  rules  will  be  developed  which  take  the  data  found  in  the  scenario  and  create  the  required 
displays.  These  rules  are  derived  from  two  sources,  pilot  expertise  and  display  expertise.  The  pilot 


15-11 


expert  provides  Instruction  concerning  Mhat  information  is  to  be  displayed  (Information  priority),  and 
when  It  Is  to  be  displayed.  The  display  expert  supplies  how  Information  Is  to  be  displayed,  where  It 
should  be  displayed,  appropriate  display  size,  display  colors,  use  of  voice,  and  any  other  pertinent 
data. 


Using  Information  about  objects  and  displays  from  the  scenario  driver  and  the  rulcbase,  graphic 
displays  for  a  crewstation  will  be  developed.  Initially  these  displays  will  reside  on  one  CRT  attached 
to  the  work  station,  however,  they  will  move  into  a  crewstation  mock-up  as  the  system  matures. 

At  the  present  time  the  development  work  station  is  in  operation  and  the  software  development  tool 
has  been  incorporated  Into  It.  Software  training  Is  complete  and  a  baseline  concept  for  display  and 
airborne  objects  is  complete.  The  specific  scenario  time  slice  has  been  Identified  and  the  development 
of  the  data  structures  is  in  progress.  The  first  demonstration  of  this  knowledge  based  Information 
manager  should  be  late  June  of  1987. 

DESIGN  EVALUATION 

The  process  of  evaluating  a  design  generated  from  the  Crewstation  Information  Management  System 
is  not  something  which  Is  done  once  and  then  forgotten.  It  is  an  ongoing  iterative  activity  which  h*:, 
been  conducted  several  times  already.  Although  the  reviews  conducted  have  been  largely  Internal,  the 
experience  of  employees  with  military  aviation  backgrounds  has  been  employed.  However,  the  major 
objective  In  the  design  evaluation  is  to  encourage  active  military  pilots  to  critically  evaluate  this 
system  both  in  the  assessment  of  control  and  display  information  criticalities,  and  in  the  crewstation 
design  implementation.  It  is  anticipated  that  a  review  of  this  nature  will  be  accomplished  within  18 
months. 


CONCLUSION 

The  discussion  of  the  Crewstation  Information  Development  System  has  been  organized  in  three  sections 
which  correspond  to  the  phases  of  system  development. 

Phase  I  presented  the  derivation  of  the  CIOS  Methodology.  Phase  II  showed  the  results  of  the 
Implementation  of  that  methodology.  P^iie  III  discussed  present  activity  and  the  direction  of  effort 
In  the  future. 

The  motivation  for  this  project  was  the  desire  to  provide  a  vehicle  whereby  the  process  of  taking 
initial  requirements  and  implementing  them  in  the  crewstation  could  be  accomplished  In  a  methodical 
way.  In  addition,  the  options  available  to  ihe  system  designer  In  the  implementation  of  requirements 
needed  to  be  organized  and  prioritized  so  that  an  optimized  design  approach  was  suggested.  From  tni$ 
process  It  Is  possible  to  develop  a  crewstation  which  encompasses  display  formats,  display  location, 
display  content,  display  prioritization,  when  to  display,  and  what  controls  to  Incorporate. 

Throughout  the  three  phases  of  activity  of  this  effort  some  important  lessons  have  been  learned, 
the  most  Important  of  which  concerns  the  development  of  requirements.  The  requirements,  as  Initially 
formatted  by  the  designer,  are  used  In  every  step  of  the  CIOS  Methodology.  These  requirements  are  allo¬ 
cated  to  several  steps  of  the  methodology  where  information  concerning  interfaces,  display  functions 
or  control  functions  Is  required.  This  dictates  that  the  requirement  must  be  very  specific,  and  have 
the  capability  to  stand  on  Us  own.  As  such,  the  results  of  the  implementation  of  the  CIOS  Methodology 
Is  highly  dependent  on  the  wording  of  the  requirements  used.  Therefore,  care  must  be  taken  In  the  Initial 
development  and  formatting  of  requirements. 

The  application  of  this  system  has  been  directed  at  the  development  of  a  new  avionic  suite  with 
a  new  crewstation.  However,  there  are  no  apparent  reasons  why  applications  to  existing  aircraft  requiring 
some  modification,  or  ground  vehicles,  are  not  viable.  Some  modifications  would  be  required  to  the 
existing  data  base,  but  the  CIDS  approach  is  workable.  In  order  to  facilitate  a  smooth  transition  to 
various  other  applications,  the  development  of  a  generic  requirements  data  base  would  be  a  valuable 
tool.  This  data  base  would  Include  basic  system  functions  such  as  navigation,  cotiwunication  etc,  and 
the  specific  program  application  would  add  to,  or  delete  from  this  generic  source  of  requirements  as 
required.  In  this  regard  considerable  time  and  manpower  savings  could  be  realized  in  the  development 
of  an  integrated  system.  This  process  can  also  provide  a  valuable  tool  to  examine  the  effects  of  failures 
on  crewstation  operation  and  the  level  of  redundancy  required  for  critical  crewstation  functions. 

In  short,  CIOS  exhibits  a  great  potential  for  supporting  the  development  of  comprehensive  displays 
and  information  management  for  state-of-the-art  weapon  systems.  The  activity  of  Phase  III  will  further 
Identify  and  clarify  the  limits  future  application. 
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SIMMARY 

In  the  past,  and  to  a  large  extent  even  today,  the  emphasis  In  system  design  has  been  on  defining 
hardware  requirements.  In  many  cases,  advances  in  hardware  technology,  and  not  the  ability  to  meet 
mission  requirements,  %fere  the  driving  factor  that  determined  the  need  for  upgrades  to  or  replacement  of 
a  weapon  system.  Even  though  software  has  increased  In  Importance  and  percentage  of  cost  in  system 
development,  it  la  still  philosophically  considered  as  a  means  to  facilitate  hardware  performance.  This 
thinking  has  had  an  adverse  effect  on  system  performance  by  relegating  decision  requirements,  which  can 
be  derived  directly  from  mission  requireaients,  to  a  minor  or  nonexistent  role  In  the  system  design 
process.  It  Is  the  premise  of  this  paper  that  system  design  should  be  dictated  by  decision  requirements 
since  decisions  humans  make  determine  how  well  and  to  what  degree  a  weapon  system's  Inherent 
capabilities  will  be  utilized.  A  system  design  approach  based  on  an  emphasis  of  the  human  in  his  role 
as  a  decision-maker  Is  presented. 


INTRODUCTION 

Historically,  even  though  the  majority  of  s^tems  designed  and  fielded  have  met  their 
specifications,  they  often  have  not  exhibited  predicted  performance.  We  believe  this  occurs  because  the 
role  played  by  the  human  In  the  system,  particularly  in  terms  of  decision  making,  has  not  been 
adequately  considered  in  the  design  process.  This  inability  to  perform  as  expected  Is  prevalent  in 
weapon  systems  and  exacerbated  with  command  and  control  (C^)  systems.  It  la  more  pronounced  as  the 
level  of  decision  dependency  Increases.  Regardless  of  decision  level  dependency,  current  design 
philosophy  Iguores  the  '.lum^n's  role.  We  pr.puse  that  It  Is  necessary  to  reorient  the  system  design 
approach,  especially  for  systems,  to  stress  the  decision  making  functloo.  Aa  a  consequence,  system 
performance  potential  could  be  maximized  by  proper  emphasis  of  the  role  played  by  humans. 

In  the  past,  and  to  a  large  extent  even  today,  the  emphasis  In  system  design  has  been  on  defining 
hardware  requirements.  In  many  cases,  advances  In  hardware  technology,  not  the  ability  to  meet  mission 
requirements,  were  the  driving  factor  that  determined  the  need  for  upgrades  to  or  replacement  of  a 
tfeapon  system.  Even  though  software  has  Increased  In  Importance  and  percentage  of  cost  in  system 
development,  it  Is  still  philosophically  considered  as  a  means  to  facilitate  hardware  performance.  This 
thinking  has  had  an  adverse  effect  on  system  performance  by  relegating  decision  requirements,  which  can 
be  derived  directly  from  mission  requirements,  to  a  minor  or  nonexistent  role  In  system  design.  It  Is 
the  premise  of  this  paper  that  system  design  should  be  dictated  by  decision  requirements  since  decisions 
humans  make  determine  how  well  and  to  what  degree  a  weapon  system's  Inherent  capabilities  will  be 
utilized. 

In  the  decision-oriented  approach  proposed,  the  system  is  considered  not  as  a  package  of  hardware 
and  software  capabilities  integrated  to  fulfill  wiell-def Ined  mlsaion  functions,  but  rather  aa  a  decision 
making  system  composed  of  three  interacting  elements— hardware ,  software  and  personnel.  The  design 
approach  based  on  this  viewpoint  begins  with  mission  requirements.  From  this,  decisions  necessary  to 
perform  specified  mission  functions,  and  hardware  and  software  needed  to  support  them,  are  then  defined. 
This  design  approach  focuses  on  maximizing  the  declslon-maklng  ability  of  an  entire  system  by  viewing 
the  three  83r8tem  components  as  complementary  and  by  Integrating  their  capabilities  synerglstlcally. 

RECENT  TRENDS  AND  POTENTIAL  SOLUTIONS 

Recent  treads,  including  more  and  better  sensors.  Improved  communication  links  and  advances  in  data 
processing  technology  have  produced  more  data  and  associated  Improvements  in  processing  capability. 
However,  large  amounts  of  data  cannot  be  assimilated  rapidly  enough  for  timely  decision  making.  In 
addition,  operational  situations  have  become  more  complex  and  faster  moving,  creating  the  need  for 
personnel  to  have  expertise  in  multiple  warfare  areas  and  to  make  decisions  in  ever  shorter  time 
periods. 

These  developments,  coupled  with  limited  human  cognitive  processing  capacity,  necessitate  the 
development  of  e3r8tems  with  a  higher  degree  of  integration  and  automation.  The  degree  of  Integration 
and  automation  required  can  only  be  achieved  by  newly  evolving  technologies  and  techniques.  The 
following  three  elements  together  may  provide  a  technology  solution  to  the  data  overload  problem: 

•  artificial  Intelligence  (Al)  technology 

•  htawn-computer  Interface  (HCI)  technology 

a  decision  augmentation  orientation 
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AI  techaologjr  will  play  a  large  role  by  providlog  automatic  and  augseoted  functional  support.  A1  Is 
a  set  of  techniques  that  can  be  eaployed  to  develop  systens  that  sloulate  hiasan  cognitive  functions, 
such  as  problem  solving,  decision  making  and  information  processing.  Advances  in  AI  are  occurring 
rapidly  and  by  the  I990'o,  AI  will  be  able  to  perform  many  decision  functions  currently  performed  by 
humans. 

HCl  technology  deals  with  the  methods  by  which  a  human  and  computer  Interact.  It  Includes  methods 
of  information  presentation,  data  entry,  and  function  sequence  control.  By  careful  structuring  of  the 
iQfsrface  and  exploitation  of  Innovative  UCI  techniques,  such  as  color  graphics,  automated  voice 
recognition  and  synthesis  display  windowing,  etc.,  information  transmission  csn  be  improved,  and  user 
learning  time  and  proceaalng  demands  reduced. 

The  proposed  system  design  approach  la  facilitated  by  Introducing  decision  augmentation.  Decision 
AuSiMOtation  software  la  designed  to  satisfy  human  information  requirements  given  a  particular  mission 
and  at  some  level  perform  the  data  to  Information  transformation.  Information  is  defined  here  as  data 
processed  to  match  the  cognitive  capability  of  the  human  and  directed  toward  a  specific  decision  task* 
Decision  augmentation  software  is  also  designed  to  quantify  information  uncertainty  and  assist  in  using 
uncertainty  In  decision  making.  The  decision  augmentation  orientation  focuses  on  the  decision 
requirements  necessary  to  successfully  accomplish  mission  objectives.  Augmenting  classical  techniques 
with  AI  and  HCI  technologies  can  provide  the  means  by  which  the  proposed  approach  can  be  Implemented  in 
the  operational  environment. 

A  decision  augmentation  framework  is  most  important  when  decision  dependency  in  the  system  is  high. 
The  first  graph  In  Figure  1  shows  that  theoretical  system  performance  using  classical  approaches  drops 
off  as  decision  dependency  increases.  The  second  one  shows  that  use  of  a  decision  augmentation  approach 
should  bring  operational  performance  closer  to  Its  theoretical  limit.  Figure  2  shows  a  simplified 
schematic  of  a  C  system  with  and  %rlthout  a  decision  augmentation  orientation.  In  either  case,  data 
including  Intelligence,  environment,  sensor,  threat,  and  own  force,  comes  Into  the  system  and  Is 
processed.  Without  a  decision  augmentation  framework,  the  processed  data  Is  pesented  directly  to  the 
decision  maker.  The  ttK>  shaded  boxes  are  added  with  a  decision  augmentation  framework.  Combining 
decision  augmentation  software  and  Innovative  Information  presentation  techniques,  tailored  to  the 
specific  decision-making  task,  should  greatly  Improve  decision-making  quality.  Decision  augmentation 
aoft«mre  can  include  any  or  all  of  the  following: 

e  "expert'*  knowledge  bases  and  decision  rules  (AI  technology) 

e  ability  to  structure  the  situation  into  a  set  of  well-defined  alternative  courses  of  action 

e  capability  to  predict  the  consequences  of  each  alternative  course  of  action 

e  rank  ordering  of  each  alternative  against  one  or  more  utility  measures 

Each  of  these,  and  other  decision  augmentation  techniques,  help  to  overcome  some  cognitive 
processing  limitations  and  biases,  and  therefore  improve  the  decision-making  process.  Hxmans  have 
limited  working  memory  and  are  not  proficient  at  doing  complex  numerical  calculations  unaided. 
Furthermore,  in  evaluating  alternatives,  they  often  make  simplifying  assumptions,  are  biased  toward 
considering  solutions  from  their  past  experience,  and  usually  do  not  simultaneously  consider  more  than 
about  three  hypotheses.  In  general,  when  confronted  with  excess  data,  people  resort  to  heuristics  which 
simplify  the  problem  and  reduce  the  amount  of  data  that  must  be  considered.  These  heuristic  biases  may, 
In  fact,  be  erroneous.  Decision  augmentation,  particularly  using  AI  techniques,  allows  more  complex 
decision  rules  to  be  Incorporated,  more  alternatives  to  be  Investigated  and  complex  and  accurate 
calculations  to  be  made.  This  provides  the  ability  to  predict  action  consequences  and  evaluate  their 
associated  utility. 

Information  presentation,  the  second  additional  box.  Is  based  on  an  understanding  of  human 
cognition,  and  includes  the  following: 

•  fusion  of  sensor  data,  presenting  only  relevant  data  formated  to  directly  support  the  decisions 
which  must  be  made 

e  use  of  graphics,  color  and  easy  access  of  backup  data  (HCI)  technology 

Mechanisms  of  information  presentation  directly  affect  the  ease  with  which  the  operator  can 
aaalmllate  and  use  the  Information  displayed  must  be  relevant  to  the  operator's  needs.  The  information 
should  be  structured,  labeled  and  coded  to  highlight  Information  content  and  relationships.  Graphic 
displays  are  superior  to  alphanumeric  displays  for  representing  overall  relationships  among  variables, 
with  alphanuawric  displays  being  most  appropriate  when  precise  information  on  specific  variables  Is 
required.  Color  Is  a  powerful  highlighting  technique  and  can  be  utilized  to  draw  attention  to  the  most 
Important  aspects  of  a  situation.  Since  the  displays  should  present  only  relevant  Information,  easy 
access  of  backup  data  should  be  provided.  Including  specific  sensor  dsta  to  resolve  conflicts,  or 
historical  data  to  analyze  specific  trends. 

LEVELS  AND  TYPES  OF  DECISION  AlXMENTATiON 

Decision  augmentation  systems  vary  In  the  level  of  automation  Involved.  They  range  from  completely 
automatic.  In  which  no  operator  action  Is  Involved,  to  manual.  In  which  only  computational  aid  is 
provided  for  the  decision  maker.  Intermediate  levels  of  decision  sugmentatlon  include  semiautomatic,  in 
which  the  system  provides  decision  alternatives  and  recommended  courses  of  action  and  the  operator 
reviews  and  accepts  or  overrides  the  system,  and  interactive,  in  which  the  operator  and  software  support 
each  other  symblotlcally.  Level  of  decision  augmentation  Is  determined  based  on.  at  a  mlninum,  the 
following  considerations : 


•  operational  situation 

•  data  load 

a  decision  iaportance 

a  intuition  likelihood 

a  user  acceptance  (with  decision  level) 

(tee  of  the  aajor  operational  situation  factors  influencing  decision  level  is  tine  in  which  a 
decision  Bust  be  aade.  Tine  to  decide  is  only  one  variable  in  the  tine  domain.  Ihree  tine  variables 
must  be  minimized  to  control  the  operational  situation. 

T  *  T  ♦  T  T 

control  collect  decide  transmit 

In  order  to  maintain  operational  control: 

T  .  ,  <  T  ,  -  T 

control  crit  op 

where:  T  ^  ■  critical  time  (time  within  which  the  operation  must  be  executed  in  order  to  have  the 

Intended  effect) 

•  time  required  to  execute  the  operation 

If  time  were  the  only  factor  impacting  decision  level,  their  inverse  relationship  would  suggest  that  the 
less  tine  available  for  decision  making,  the  higher  the  level  of  autonomy. 

Even  though  tine  should  be  considered  the  most  important  factor  when  determining  which  decision 
augmentation  level  to  use,  all  factors  listed  (and  perhaps  others)  must  be  considered.  Table  1  shows 
the  relationship  between  the  five  independent  factors  and  decision  augmentation  (DA)  level  in  terms  of 
an  idealistic  environment.  It  is  easy  to  envision  in  a  realistic  environment  that  conflict  among  the 
factors  is  not  only  possible  but  highly  likely,  e.g.,  between  operational  environment  and  decision 
importance.  If  the  decision  is  to  have  its  intended  impact,  it  may  be  necessary  to  have  decisions  made 
automatically  when  the  critical  time  is  very  short,  e.g.,  acitlvate  SDI  to  maximize  boost  phase  kill,  a 


very  important 

decision. 

Table  1 

1 

OPERATIONAL 

BNVIROWIENTAL 

DATA 

LOAD 

DECISION 

IMPORTANCE 

USER 

ACCEPT 

INTUITION 

LIKELIHOOD 

LEVEL  OF  DA 

Autosiatic 

■'crit  ■  ® 

High 

Low 

* 

Low 

Semi-Auto 

High 

Mod 

* 

Low 

Interactive 

'crit  ® 

Mod 

Mod 

* 

Mod 

Manual 

'CRU  >»  ® 

Low 

High 

* 

High 

E  «  Short  Time 
*  Variable,  a 

Function  of  User 

Hie  level  of  decision  augmentation  desired  determines  which  techniques  should  be  used  in 
implementation.  Figure  3  shows  where  in  the  requirements  analysis  process  this  determination  should  be 
made  and  how  it  influences  information  processing  and  the  HCI  requirements.  The  type  of  decision 
augmentation  techniques  should  >e  chosen  to  match  decision  situation  requirements,  tfhile  A1  (expert 
system)  techniques  will  prove  extremely  valuable,  they  are  not  applicable  to  all  situations  and  should 
not  be  considered  a  panacea.  A  number  of  taxonomies  for  decision  situations  and  decision  aiding 
techniques  have  been  proposed  (Keen  and  Scott-Morton,  1978,  Rouse,  1984;  Wohl,  1981;  Zachary,  1986) 
which  may  prove  useful  in  determining  the  type  of  decision  augmentation  technique  to  use.  Zachary 
suggests  a  taxonomy  for  decision  augmentation  based  on  the  kinds  of  congitlve  support  that  the  various 
computational  techniques  provide  to  human  decision  makers.  For  example,  deterministic  or  stochastic 
process  models  support  the  selection  of  an  action  from  a  set  of  known  alternatives  by  projecting  the 
implications  of  each  alternative  based  cn  assumptions  about  the  process.  In  order  to  support  reasoning 
processes  in  ill-structured  problems  with  incomplete  or  contradictory  data,  AI  techniques  can  be 
employed  to  provide  symbolic  reasoning  capabilities  based  on  a  body  of  knowledge  and  specific  kinds  of 
inferencing  procedures.  Representational  aids  such  as  pictorial  or  spatial  representations  help  the 
decision  maker  develop  an  understanding  of  a  complex  situation.  Database  management  tools  allow  the 
user  access  to  subsets  of  complex  data  aggregated  according  to  a  number  oL'  predefined  or  ad  hoc 
criteria,  other  types  of  tools  support  other  decision  making  needs. 

Wbrking  with  the  area  of  tactical  command  and  control,  tfohl  presents  a  decision  aid  taxonomy  based 
on  the  anatomy  of  tactical  decision  processes,  called  the  SHOR  model.  The  SHOR  model  defines  four 
elements  of  a  decision:  Stimulus  (data),  Hypotheais  (perception  alternatives),  Option  (response 
alternatives),  and  Response  (action).  Information  processing  techniques  are  identified  which  are 
appropriate  to  each  part  of  the  decision  process,  depending  on  processing  complexity,  the  tine  available 
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foe  Che  decision  and  the  degree  of  information  aggregation  required.  Some  processing  aids  suggested 
Include;  Sensor  correlation  aids,  eoom  In/out  trlth  variable  detail,  speeded-up  play  back  of  selected 
battlefield  history  by  target  or  unit  type,  knovledge/rule  based  systems,  If/then  triggers,  English 
language  data  base  access  and  pattern  recognition  aids,  among  others. 

DECtSlON-ORlENTEO  SYSTQ1  DESIGN 

2 

The  usability  of  a  weapon  or  C  system  Is  ultimately  a  reflection  of  Its  design  philosophy.  The 
most  commonly  applied  system  design  approach  begins  with  a  detailed  statement  of  platform  mission 
requirements.  Mission  requirements  are  then  used  to  derive  functional  requirements  that  will  support 
successful  mission  accomplishment.  The  fttnctlonal  requirements  are  allocated  to  either  hardware  of 
software  elements  of  the  system.  In  practice,  this  approach  emphasises  hardware  considerations,  with 
softMre  being  designed  to  facilitate  hardware  use. 

Because  informed,  timely  and  "correct''  decisions  are  the  key  element  In  system  effectiveness,  system 
design  should  be  based  on  decision  requirements.  System  hardware  and  software  should  be  specified  and 
designed  to  support  the  decision  making  function.  Requirements  should  be  based  on  operational 
performance  deficiencies  rather  than  on  advanced  technology,  which  is  the  tei.uency  In  a  hardware 
oriented  design  approach. 

Figure  4  defines  an  R4D  approach  which  can  be  systematically  applied  to  develop  a  system  (or  a 
weapon  s)ntem)  on  a  decision-oriented  basis.  This  design  approach  also  begins  with  the  specification  of 
mission  requirements.  Subsequent  steps  attempt  to  develop  more  specific  system  and  subsystem  functions 
to  fulfill  the  primary  mission  requirements,  as  la  currently  done.  Based  on  the  mission  analysis,  all 
decisions  necessary  to  perform  specified  mission  functions  are  defined.  The  step  of  defining  decision 
requirements  is  done  early  In  the  requirements  analysts,  and  serves  as  the  determinant  of  all  hardware 
and  software  requirements.  After  the  decision  requirements  are  specified,  each  decision  is  analyzed  to 
identify  the  information  needed  to  make  the  decision.  "Infontatlon"  implies  data  that  has  been 
processed  and  reduced  to  just  the  elements  needed  for  the  decision.  Next,  the  data  necessary  to  provide 
decision-specific  information  is  defined.  '‘Data"  refers  to  data,  (e.g.,  target  contact  reports)  that  is 
needed  to  derive  decision-specific  Information.  These  three  steps  are  critical  because  they  serve  as 
the  basis  for  developing  all  detailed  requirements  in  the  system  specification. 

Once  the  data  necessary  to  provide  decision-specific  information  have  been  defined,  the  hardware  and 
software  (both  decision  augmentation  and  other  support  software)  requirements  are  specified.  As  Figure 
4  shows,  there  are  three  parallel,  but  not  independent,  paths  for  specification  of  decision  augmentation 
software,  support  software  and  hardware  requirements.  The  emphasis  on  the  decision  function  suggests 
that  the  middle  path,  that  of  defining  decision  augmentation  software,  is  the  leading  path.  First,  It 
is  necessary  to  identify  the  source  of  each  data  element.  Then,  decision  functions  and  their 
information  requirements  must  be  allocated  to  organizational  units/ individuals  and  subsequently  to  human 
(apeclfc  organizational  unlts/lndlvidual)  versus  computer  (decision  augmentation  software).  The 
human/computer  allocation  should  be  based  on  the  relevant  capabilities  and  limitations  of  each. 

Decision  augmentation  requirements,  including  Hul  requirements,  should  then  be  derived  based  on  an 
analysis  of  the  decision  problem  and  the  techniques  to  assist  that  particular  decision  problem. 

The  left-hend  path,  that  of  defining  support  software  requirements,  is  based  on  the  data  necessary 
to  provide  decision-specific  information  aa  well  as  the  decision  augmentation  software  requirements. 

The  support  software  might  include  operating  systems,  device  handlers  and  data  base  management  systems. 

The  design  approach  shows  hardware  requirements,  the  right-hand  path,  also  being  dependent  on  the 
"Define  Data"  task.  First,  the  date  parameter#  are  defined.  Hardware  performance  requirements  are 
stipulated  based  on  the  hardware's  capability  to  provide  the  data  parameters  (or  performance)  specified. 
This,  then,  determines  the  hardware  specification,  l.e.,  the  ability  to  provide  the  data  needed  to 
produce  information  required  for  decision  making.  The  hardware  elements  Include  sensors,  which  must 
furnish  specified  data  at  a  certain  rate  and  accuracy  to  allow  a  meaningful  and  timely  decision  to  be 
made;  computers  which  must  have  the  requisite  capacity  and  computational  speed;  and  communclatlons 
systems  which  must  have  the  required  connectivity  and  bandwidth  to  handle  data  transmission  load. 
Developing  hardware  requirements  based  on  the  decision  maker's  needs  will  provide  a  better  fusion 
between  these  system  components,  resulting  In  a  higher  level  of  performance  than  previously  achieved  by 
using  the  current  system  design  approach. 

After  the  hardware,  support  software  and  decision  augmentation  specifications  have  been  defined,  the 
hardware/software  Interface  specification  can  be  defined.  By  combining  these  specifications 
appropriately,  the  overall  system  speclflcatln  can  be  developed.  What  will  result  Is  a  C  system  (or 
weapon  system)  that  has  a  greater  likelihood  of  meeting  Its  theoretical  performance  level. 

ORGANIZATION  ANALYSIS 

Reorientation  of  the  system  design  approach  to  emphasize  the  human  and  his  decision  making 
responsibilities  requires  analyses  that  are  not  considered  In  the  current  approach.  These  analyses  are 
qualitative  and  concentrate  on  factors  that  contribute  to  the  framework  of  decision  making  In  an 
organizational  envlronoMnt.  The  analysis  methods  and  data  sources  for, the  Initial  requirements  analysis 
are  shown  In  Figure  3.  Mission  requirements  are  determined  by  a  functional  analysis  of  operational 
problems  and  deficiencies,  Including  tactics,  sensor  utilization,  sensor  performance,  available 
resources,  and  enemy  order  of  battle.  Decision  requirements  are  Identified  by  going  directly  to  the 
decision  makers.  Non-quantltatlve  behavloral/soclal  science  methods  such  as  questionnaires,  interviews, 
verbal  protocols  and  observation  of  the  decision-maker  in  his  operatlnal  environment  should  be  employed. 
Analysis  of  the  operational  and  organizational  environment  Is  also  crucial.  It  should  include 
identification  of  the  follotrlng  elements: 


Infernal  as  well  as  fomal  connunlcation  link# 


•  apportloonaot  of  declalon-naklng  responalblllty  Co  conponenta  of  an  organlsaclon 

•  relationships  between  organizations 

•  what  decision  aids  (autonated  or  not)  are  currently  being  used  or  could  be  used  If 
available. 

Analysis  of  these  and  other  organizational  elenents  will  enhance  the  ability  to  correctly  define 
decision  requlrenents  and  to  detemlne  the  appropriate  level  of  decision  augnentatlon. 

TECHNOLOGY  XHPLICATIONS 

^phasls  on  decision  waking  functions  has  a  nunber  of  Inpllcatlons  for  the  design  and  laplenentatlon 
of  C  systens  (and  weapon  aystena).  Five  ace  discussed  below. 

First,  a  basic  understanding  of  human  cognitive  processing  Is  required  to  fully  realize  decision 
augnentatlon  potential.  C  systens  should  be  designed  to  provide  assistance  In  chose  areas  where  hunan 
capability  is  United  while  still  capitalizing  on  htaan  strengths.  For  exanple,  humans  have  attention 
and  memory  limitations.  Inherent  heuristics  which  ttMy  employ  In  Information  processing  and  llmmlted 
ability  to  process  nunerlcal  data  In  complex,  stressful  and  data  overload  situations.  These  are  areas 
In  which  decision  augmentation  can  provide  significant  Improvements  over  unaided  decision  making. 

Second,  HCl  design  can  affect  decision  behavior;  therefore.  Its  effects  should  be  considered  In 
system  design.  Decision  augmentation  system  design  la  often  concerned  with  methodological  validity, 
without  sufficient  attention  to  the  relationship  between  it  and  Che  user  (e.g.,  the  amount  and  kind  of 
user-augmentation  Interaction,  dialogue  style.  Information  presentation  formats,  Schwartz  and  Jamar, 
1983).  If  results  of  decision  augmentation  are  not  preMnted  in  a  directly  useable  format  with  due 
consideration  to  the  user's  needs  and  desires,  they  will  not  be  effecltvely  used.  Importance  of  the 
Interface  betieeen  human  and  computer  has  received  Increased  attention  In  recent  years  and  Is 
particularly  critical  In  situations  In  which  decisions  must  be  made  under  time  pressure  or  conditions  of 
high  data  volume.  Some  examples  of  good  interface  design  features  are: 

•  use  of  graphics  to  represent  situational  overvle«m,  particularly  geographic  representations 

a  provide  only  that  Information  needed  to  support  a  decision  situation 

•  display  historical  data  on  request 

•  provide  embedded  training  and  on-line  tutorials  to  facilitate  use  by  both  novices  and  experts 

e  provide  easy  means  of  user-computer  communication 

•  make  the  knowledge  base  and  decision  rules  In  decision  augmentation  systems  accessible  so  the 
user  can  query  them 

•  Insure  computer  response  speeds  are  commensucate  with  user  expectations 

•  provide  automatic  sK>de  settings  Chat  users  can  override  (e.g.,  number  of  alternatives  display, 
what  utility  measure  to  order  alternatives  on) 

•  provide  suggestive  rather  than  authoritative  output 

•  provide  succinct  rather  than  converaatlonal  output 

Third,  improved  understanding  of  and  attention  to  Innovation  acceptance  is  needed.  Whether  a 
decision  system  is  used  or  not  will  depend  not  only  on  Its  design  but  also  how  It  is  Introduced  (Hackle 
and  Wylie,  1983).  The  system  must  be  designed  so  that  It  meets  the  user's  needs  rather  than 
Introducing  additional  workload.  Even  If  the  system  Is  actively  Involved  In  the  declslon-maklng 
process,  and  In  some  cases  excludes  the  hman,  it  should  not  appear  to  erode  Individual  control  or 
decision  making  authority.  System  operation  should  require  only  mlnmum  knowledge  of  computers  and 
should  not  Involve  complex  operating  procedures.  The  user  community  should  be  Involved  throughout  the 
development  process  to  facilitate  the  Introduction  of  new  decision  automation  systens  (Melman,  1982). 
They  should  be  involved  early  In  the  development  cycle,  when  system  requirements  analysis  is  being 
conducted.  Also,  prior  to  system  introduction,  potential  users  should  be  briefed  on  system  capabilities 
and  operating  procedures  so  they  know  what  to  expect  and  can  take  full  advantage  of  what  Is  provided. 

Fourth,  AI  technology  Is  rapidly  becoming  accepted  as  s  major  tool  for  Implementing  decision 
augmentation  83rstem8.  It  allows  the  use  of  more  complex  decision  rules  In  addition  to  OMerlcal 
computations  and  algorithms.  Furthermore,  the  knowledge  of  experts  can  be  acquired  and  encoded  Into  the 
system  knowledge  base. 

Finally,  decision  augmentation  systems  should  be  able  to  adapt  to  both  user  and  environment.  In 
order  to  make  the  system  adaptable,  the  system  architecture  In  which  the  knowledge  base  and  decision 
rules  reside  must  permit  change.  It  should  be  possible  to  update  when  new  tactical  situations  arise  or 
other  environmental  changes  occur.  Also,  there  are  Individual  differences  among  decision  makers  both  in 
decision  making  style  and  the  Importance  they  place  on  different  criteria  In  determining  a  final 
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decision.  This  Individuality  should  be  sccoaaodaced  to  the  extent  possible  using  Innovative 
architecture  until  technology  has  evolved  to  the  point  irhere  learning  can  be  an  Integral  part  of  the 
decision  augnentatlon  systea.  The  current  aystea  design  approach  does  not  bring  Into  focus  the 
technology  laplicatlons  discussed.  It  la  only  through  a  decision  oriented  design  approach  that  full 
advantage  can  be  made  of  the  new  technology. 


SIMM  ARY 

2 

As  a  consequence  of  the  Increased  data  voluae  in  current  and  future  C  systeas  and  the  llalcations 
In  human  cognitive  processing  capacity,  a  reorientation  of  the  systea  design  process  has  been  proposed. 
In  the  approach  proposed,  aystea  design  la  based  on  decision  requirements  rather  than  on  hardware 
perforaance.  Also,  decision  augmentation  techniques  and  Innovative  Information  presentation  are  needed 
to  reduce  the  data  overload.  The  higher  degree  of  Integration  and  automation  possible  with  decision 
augmentation  systeas  coupled  trlth  the  eaphasls  on  decision  functions  should  greatly  reduce  the  Incoming 
data  load  so  that  the  decision  maker  can  devote  more  time  to  thinking  about  operational  problems  rather 
chan  merely  reacting  to  the  task  environment.  If  these  changes  can  be  accomplished,  systea 
capabilities  should  Improve,  and  as  a  consequence.  Increased  mission  effectiveness. 
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FIGURE  1.  SYSTEM  PERFORMANCE  DEPENDENCIES 
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FIGURE  3.  IMPACT  OF  DECISION  AUGMENTATION  LEVEL 


lA-K 


I  SPECtfY  MISSION  ffiOUlAE>€NTS 


I - 


lOCNTIFT  DECISION 
^OUIftENCNrS 

^  1 

_ I _ 


FIGURE  4.  DECISION-ORIENTED  SYSTEM  DESIGN 
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Summary 

The  application  of  new  technologies  such  as  VHSIC,  and  new  system 
concepts  such  as  artificial  Intelligence,  distributed  operating  systems,  common 
hardware  components,  and  reusable  software  modules/libraries  has  changed 
the  manner  in  which  avionics  suites  are  designed,  developed,  and  verified. 
The  requirements  for  developing  these  systems  are  specified  in  U.S.  military 
standards  and  can  be  segregated  into  requirements  for  the  overall  system, 
configuration  Items,  Interfaces,  and  the  design  process  management. 
Northrop  has  developed  a  design  process  and  methodology  capable  of  meeting 
these  system  development  requirements  which  Involves  time  phased  analyses, 
requirements  analysis  and  decomposition,  functional  decomposition,  and  system 
synthesis  and  interface  definition.  This  process,  developed  through  past 
advanced  avionic  system  design  efforts,  is  now  being  automated  through  the 
development  of  a  set  of  tools  to  manage  all  phases  of  advanced  avionic  system 
design,  the  Avionic  System  Engineering  Tool  (ASET). 

I.  Advanced  Avionic  System  Design  Requirement! 

The  design  of  any  system  includes  key  elements  such  as  software,  hard¬ 
ware,  and  interfaces.  Although  the  requirements  for  these  elements  can  be 
specified  in  any  number  of  ways,  the  U.S.  Department  of  Defense  (DoD)  has 
mandated  a  specific  set  of  documents  to  contain  these  requirements.  These 
documents  are  defined  in  MIL-STD-483,  MIL-STD-490,  and  DoD-STD-2167 ,  and 

include  a  description  of  the  following  requirements  for  advanced  avionic  sys¬ 
tem  design: 

1.  Overall  system  requirements.  These  requirements  include  the 
following: 

a.  Definitions  of  the  major  functions  of  the  system,  and  the 
principal  interfaces  between  those  functions 

b.  The  allocation  of  performance  requirements  and  specific  design 
constraints  peculiar  to  each  system  function 

c.  The  definition  of  the  principal  interfaces  between  the  system 
being  specified  and  other  systems  with  which  it  must  be 
compatible 

d.  The  operating  requirements  for  logistically  and  technically  sup¬ 
porting  the  ayatem 

e.  The  design  requirements  necessary  to  assure  compatibility  of 
system  equipment  and  software 

f.  The  identification  and  relationship  of  Hardware  Configuration 
Items  (HWCIs)  and  Computer  Software  Configuration  Items 
(CSCls)  which  comprise  the  system. 

2.  Configuration  Item  requirements.  These  requirements  include  the 
following: 

a.  The  detailed  functional,  performance,  interface,  and  qualifica¬ 
tion  requirements  of  all  Configuration  Items  (CIs) 
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b.  The  identiflcetton  end  relationship  of  the  components  of  all  CIs 

c.  The  requirements  for  pro^amming  design,  adaptation,  quality 
factors,  and  traceability  of  all  CIs 

d.  The  Identification  of  the  subset  of  the  overall  system  require¬ 
ments  allocated  to  each  Cl. 

3.  Interface  requirements.  These  requirements  include  the  following: 

a.  The  detailed  requirements  of  the  interfaces  between  all  com¬ 
ponents  of  the  system 

b.  The  methods  by  which  these  interfaces  will  be  verified. 

4.  Design  process  management  requirements.  These  requirements 
include  the  following: 

a.  Plans  for  the  development,  test,  configuration  management,  and 
quality  assurance  of  the  system  and  the  CIs  within  the  system 

b.  Documents  describing  the  procedures  to  be  followed  during  the 
development,  test,  configuration  management,  and  quality 
assurance  of  the  system 

c.  Documents  describing  the  procedures  and  information  necessary 
to  maintain  the  system  after  it  is  passed  on  to  a  customer. 

These  requirements  must  be  generated  during  the  design  of  any  sys¬ 
tem.  Section  II  will  detail  the  process  by  which  Northrop  has  satisfied  these 
requirements  in  the  past,  and  Section  III  Illustrates  how  this  process  is  being 
automated  to  improve  the  accuracy  and  efDdency  of  Northrop'a  advanced 
avionic  system  designs. 

li.  Advanced  Avionic  Syitem  Detign  Process 

The  avionic  system  design  process  traditionally  consists  of  four  steps, 
repeated  iteratively  until  a  satisfactory  system  design  is  accomplished. 

1.  Abstract  requirements  identification.  The  process  of  requirements 
identification  involves  determining  the  high  level  requirements  of 
the  avionic  system.  These  abstract  requirements  are  derived  from 
mission  phase  decompositions  and  system  timeline  analyses,  or  can 
be  extracted  directly  from  Statement  of  Work  (SOW),  Contract 
requirements,  System  Requirements  Document  (SRD),  or  Weapon 
System  Specincation  (WSS). 

2.  Requirements/functional  decomposition.  The  requirements  arrived  at 
during  the  abstract  requirements  identification  phase  of  system 
design  are  usually  not  those  directly  usable  in  the  design  of  a  sys¬ 
tem.  Prior  to  performing  actual  system  design,  these  requirements 

must  be  refined.  For  example,  a  requirement  such  as  **The  system 

2 

must  be  capable  of  displaying  a  target  of  20  m  at  25  nm**  could  be 
refined  by  the  systems  engineer  into  the  following: 

a.  "There  must  exist  s  sensor  capable  of  detecting  a  target  of 

2 

20  m  at  25  nm." 

b.  "There  must  be  a  display  system  capable  of  showing  a  target  to 

2 

the  pilot  with  a  range  of  25  nm  and  20  m 

c.  "There  must  be  a  communications  path  between  the  sensor  and 
display  system  called  out  above." 
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This  procedure  of  refining  requirements  continues  until  the  process 
phases  into  a  functional  description  and  decomposition  procedure. 
This  point  is  reached  when  the  systems  engineer  describes  a  func¬ 
tion  which  performs  the  requirements,  rather  than  simply  describing 
the  requirements  in  increasingly  greater  detail.  An  example  of  this 
would  be  the  definition  of  a  Head-Up  Display  (HUD)  in  order  to 
meet  a  portion  of  the  requirements  of  the  display  system  listed 
above. 

This  process  is  also  characterised  by  decomposing  and  refining 
requirements  or  functions  from  different  viewpoints.  In  other 
words,  the  system  can  be  described  from  the  viewpoint  of 
non-combat-fllght  vs^  alr-to-alr  vs.  air-to-ground,  or  offensive  vs. 
defensive,  or  even  from  the  viewpoint  of  the  hardware  system  as  it 
is  currently  defined.  Examining  the  system  from  these  disparate 
viewpoints  will  often  identic  requirements  or  functions  not  illus¬ 
trated  during  the  original  decomposition.  It  must  be  noted  that  the 
same  lower  level  requirement  or  function  can  be  arrived  at  from 
different  higher  level  entities,  i.e.,  the  HUD  specified  above  would 
meet  the  requirements  for  the  display  of  many  items,  not  only  the 
target  at  25  nm.  Another  aspect  of  this  phase  of  system  design  is 
the  assignment  of  functional  inputs,  outputs,  estimates  of  memory, 
throughput,  sise,  weight,  and  power. 

Finally,  the  result  of  this  phase  of  system  design  is  the  detailed 
description  of  s  large  set  of  functions  which  must  be  performed  by 
the  avionic  system. 

Functional  recomposition.  The  functional  recomposition  process 
Involves  taking  the  large  set  of  functions  arrived  at  during  the 
requirements/functional  decomposition  phase  of  the  system  design, 
and  grouping  these  functions  into  increasingly  larger  sets.  For 
example,  all  functions  dealing  with  the  display  of  targets  in  air- 
to-air  mode  might  be  grouped  together.  Then  this  set  could  be 
included  in  the  set  containing  air-to-ground  target  display  func¬ 
tions,  to  form  an  all-mode-targct  display  group.  This  process  con¬ 
tinues  until  all  functions  have  been  included  into  groups,  all  of 
which  have  been  grouped  into  the  complete  system. 

This  functional  recomposition  Is  performed  by  the  system  engineer, 
and  requires  forethought  and  research  prior  to  performing  the 
groupings.  The  tasks  the  engineer  is  accomplishing  in  this  phase 
of  system  design  include  the  following: 

a.  The  definition  of  the  system  elements,  from  the  most  detailed 
descriptions  of  functions  to  the  actual  Line  Replaceable  Units/ 
Line  Replaceable  Modules  (LRUs/LRMs) 

b.  The  assignment  of  signal  paths  for  all  input/output  pairs  within 
each  group,  as  that  group  is  created 

c.  The  summation  of  the  estimates  (memory,  .hroughput,  size, 
weight,  etc.)  of  the  lower  level  functions  into  estimates  of  the 
high  level  groupings. 

The  end  result  of  the  functional  recomposition  phase  is  the  actual 
system  design,  minus  the  detailed  interface  definitions. 


4.  Detailed  interface  definition.  During  the  detailed  interface/bus 
definition  phase  of  systeis  design,  the  engineer  first  defines  and 
then  assigns  the  information  associated  with  each  signal  path  within 
the  system.  In  other  words,  the  engineer  chooses  the  communica¬ 
tions  path  (i.e..  bus,  memory  link,  etc.)  to  be  used  for  a  gfiven 
algnal  path,  defines  the  information  specific  to  that  communications 
path,  and  then  assigns  the  bus-specific  information. 

During  the  requirements/ functional  breakdown  phase  of  the  system 
design,  an  engineer  assigns  inputs  and  outputs  to  the  functions 
within  the  system.  These  signal  definitions  include  information 
such  as  frequency  of  update,  units,  maximum/minimum  value,  etc. 
These  definitions  do  not  Include  information  specific  to  a  certain 
bus,  such  as  remote  terminal  number,  message  number,  bit  posi¬ 
tion,  etc.  Not  only  la  this  information  bus-specific,  but  the  task  of 
assigning  this  information  during  the  requirements /decomposition 
phase  is  extremely  complex,  and  requires  very  good  communications 
between  different  engineers.  After  all  signals  traveling  on  a  path 
are  defined,  however,  the  task  becomes  greatly  simplified.  There¬ 
fore,  the  mapping  of  the  signals  onto  the  bus-specific  layout  is 
accomplished  after  functional  recomposition,  after  the  signals  are 
defined  and  specified  for  each  bus. 

This  four-step  process  Is  repeated  many  times,  with  the  end  result 
being  the  system  design.  This  system  design  is  captured  in  docu¬ 
ments  defined  by  the  MIL-STD  and  DoD  speciflcstions.  and  fulfills 
the  requirements  of  the  system  design  as  defined  in  Section  I.  The 
correlation  between  these  requirements  and  the  system  design 
phases  Is  shown  in  Figure  1. 

Ml.  Automatsd  Tools  for  Syitsm  Design 

Automated  tools  can  greatly  aid  in  the  avionic  system  design  process, 
providing  more  efficient,  more  easily  managed,  and  more  accurate  system 
designs.  For  these  tools  to  be  truly  usable  suid  effective,  however,  the  fol¬ 
lowing  requirements  must  be  followed: 

1.  Information  regarding  tools  on  the  system  must  be  disseminated  to 
all  potential  users,  not  only  those  specifically  targeted  for  tool  use. 

2.  The  tools  and  systems  must  be  capable  of  expanding  and  accommodat¬ 
ing  new  tools,  migrating  to  new  systems,  accepting  larger  and  more 
elaborate  problems  and.  In  genera],  supporting  the  future  require¬ 
ments  of  avionics  engineering  as  well  as  the  current  needs.  Much 
of  this  requirement  has  been  fulflUed  simply  by  documenting  to 
MlL-STD-2i67.  coding  in  a  Higher  Order  Language  (HOL),  and 
making  full  use  of  the  HOL*8  built-in  modularity  capabilities. 

3.  The  tools  must  be  able  to  be  quickly  and  efficiently  Integrated  into 
the  existing  Avionics  Engineering  environment.  This  involves  the 
utilization  of  currently  existing  hardware  (terminals  and  main¬ 
frames)  .  as  well  aa  maintaining  a  user  interface  very  similar  to 
existing  tools. 

4.  The  ioola  must  be  both  powerful  and  user-friendly.  The  moat 
involved  on-line  queries  must  take  less  than  30  seconds;  typical 
operations  must  take  far  leas.  In  addition,  the  tools  must  include 
extensive  help  utilities. 
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FIGURE  1.  REQUIREMENTS  FULFILMENT  BY  DESIGN  PHASE 

5.  Th«  tooli  must  not  require  e  long  leernlng  curve  to  achieve  Initial 
benefits. 

6.  The  tools  must  be  capable  of  providing  hardcopy  output  for  review 
by  others  (such  as  subcontractors). 

7.  The  tools  must  facilitate  securing  any  information  entered  into  the 
system. 

Northrop's  Aircraft  Division  is  developing  an  automated  tool  called  the 
Avionic  System  Engineering  Tool  (ASET).  The  ASET  fulfills  all  of  the  just- 
listed  requirements,  and  is  intended  to  provide  engineers  the  ability  to  per¬ 
form  the  end-to-end  system  design  process  more  quickly  and  effectively , 
while  improving  both  the  turnaround  time  and  accuracy  of  the  documents 
associated  with  the  system.  The  ASET  will  also  provide  traceability  from  all 
levels  of  requirements  through  the  actual  system  hardware  and  software  CIs. 

Past  system  design  efforts  have  relied  on  paper-based  documentation 
which  was  often  out-of-date,  difficult  to  understand,  inte^^naJIy  Inconsistent, 
and  usually  did  not  reflect  the  entire  avionic  system.  As  a  result,  the  test 
engineers,  software  developers,  subcontractors,  Implementors,  etc.,  had  to 
rely  on  conversations  with  the  original  designer  of  any  system  to  determine 
exactly  what  had  been  specified. 

Another  difficulty  of  the  paper-based  documentation  scheme  is  the  sepa¬ 
ration  of  the  engineers  from  their  output.  The  design  engineers  prepare 
their  work  on  paper,  which  is  redone  by  either  their  secretary  or  drafting 
personnel  for  placement  in  the  document.  The  personnel  requiring  this  infor¬ 
mation  must  then  acquire  a  copy  made  of  the  document. 

The  manner  in  which  the  ASET  overcomes  many  of  the  difficulties  of  the 
paper-based  documentation  effort  Is  by  Involving  the  avionic  system  designers 
themselves  in  the  process  of  generating  the  system  representation.  This  does 
not  mean  that  they  have  to  involve  themselves  in  standard  data  entry  func¬ 
tions.  The  ASET  allows  the  engineers  to  perform  their  jobs  in  the  same  man¬ 
ner  that  they  have  always  performed  their  jobs,  only  faster,  as  if  they  had 
an  intelligent  piece  of  paper  and  pencil;  ASET  is  recording  their  work  and 
saving  it  for  later  steps  in  the  process.  Thus,  ASET  improves  upon  the 


cysten  enginMring  process  by  sUowing  the  design  engineers  to  manipulate 
and  create  the  actual  system  representation  accessed  by  the  personnel 
requiring  this  information. 

The  ASET  has  been  divided  into  four  subtools  •  the  Timeline  Analyser 
Subtool  (TAS).  the  System  Analysis  Subtool  (SA5).  the  System  Generation 
Subtool  (SGS).  and  the  Interface  Definition  Subtool  (IDS),  which  correspond 
to  each  phase  of  the  system  design  process,  as  shown  in  Figure  2. 


SYSTEM  OESKM 

system  oesion 
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DEFINITION 
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FIGURE  2.  ASET  SUBTOOL  CORRELATION  MATRIX 

The  TAS  allows  the  engineer  to  enter  mission  phases  into  a  timeline, 
and  then  decompose  any  phase  of  that  mission  Into  a  complete,  lower  level 
timeline.  In  addition,  the  TAS  provides  full  cut-and-pastc  cspsbllltles.  and 
la  able  to  pass  the  requirements  entered  by  the  engineer  onto  the  System 
Analysis  Subtool. 

The  SAS  provides  the  capability  to  perform  requirements/functional 
decomposition  on  the  CRT,  alternating  between  displaying  the  requirements 
tree  as  it  la  created,  or  displaying  the  requirements/functions  and  the 
entities  above  and  below  them  in  the  tree.  The  SAS  provides  signal 
verification,  verifies  hierarchicad  consistency,  and  provides  for  both  redun¬ 
dancy  and  nebulous  requirements  fulflllrocnt  checking.  The  SAS  provides  cut- 
and-paste  functions  on  the  tree,  and  also  generates  the  set  of  functions 
paased  on  to  the  System  Generation  Subtool. 

The  SGS  allows  the  engineer  to  perform  the  functional  recomposition  of 
the  system,  collecting  like  functions  upon  command,  and  allowing  the  engineer 
to  specify  which  of  the  functions  within  the  collection  to  group.  In  addition, 
the  SGS  performs  I/O  verification,  allows  assignment  of  signals  to  rignal 
paths,  and  rebuilds  the  memory,  throughput,  size,  weight,  etc.,  estimates 
for  each  grouping  within  the  system.  The  SGS  builds  the  database  which  is 
used  by  the  Interface  Definition  Subtool. 

The  IDS  allows  the  user  to  define  and  then  enter  all  bus-specific  infor¬ 
mation  associated  with  each  signal  in  the  database.  The  IPS  also  provides 
the  capability  to  generate  documents  based  on  the  information  entered  by  the 
user  such  as  the  Interface  Requirements  Specifications  and  Sections  3  and  4 
of  the  System  Requirements  Specifications,  and  is  capable  of  providing  infor¬ 
mation  to  CADAM  systems  for  the  generation  of  system  layouts,  wiring  dia¬ 
grams,  etc. 
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IV.  ASETBwMfHs 

1.  Requirements  Traceability.  The  ASET  permits  the  users  to  trace 
fr«n  any  requirement  or  function  within  the  system  (entered  or 
generated  In  the  SAS),  to  the  final  avionic  system  or  systems  that 
fulfill  that  requirement.  This  permits  anyone  to  determine  exactly 
what  requirements  are  fulfilled  by  any  particular  LRU/LRM,  and 
to  determine  exactly  which  LRUs/LRMs  fulfill  any  particular 
requirement. 

2.  Contract  Modification  Response  Improvement.  Due  to  the  require¬ 
ments  traceability  of  the  ASET,  the  impact  of  any  changes  to 
system  requirements  can  immediately  be  determined. 

3 .  I/O  Verification.  The  ASET  verifies  that  all  signals  within  the 
system  (input  through  the  SAS)  have  constructs  which  generate, 
transfer,  and  receive  these  signals. 

4.  Throughput  and  Memory  Analysis.  The  ASET  requests  the  systems 
engineer  to  input  memory  and  throughput  estlmatea  for  each  bottom 
le\^el  function  within  the  SAS.  When  the  system  grouping  is  being 
accomplished,  these  memory  and  throughput  estimates  are  combined 
to  give  estimates  for  any  subset  of,  or  the  entire,  avionics  system. 

5.  Improved  Inter-  and  Intra-Group  Communications.  Communications 
between  different  groups  will  improve  due  to  the  better  system 
description  being  available.  Communications  within  the  systems 
engineering  group  will  improve  because  engineers  will  be  able  to 
"try  out"  their  design  with  the  other  tentative  designs  of  the 
system.  This  will  result  In  an  even  faster  and  more  effective 
system  design  process. 

6.  Improved  Software  Design  and  Test.  With  the  development  of  a 
better  designed  and  documented  avionics  system .  the  software 
design  end  software  test  personnel  will  perform  more  efficiently, 
which  will  result  In  a  more  reliable,  effective,  and  error-free 
system. 

In  addition  to  all  that  has  been  apeclfied,  the  ASET  has  been  modularly 
designed  tc  easily  accommodate  enhancements  such  as  the  following  r 

1.  Autcmotic  code  generation  for  portions  of  the  system.  One  of  the 
first  enhancements  planned  for  the  ASET  is  the  association  of  a 
Program  Design  Language  (PDL).  the  Implementation  of  which  may 
be  Ada,  with  each  element  In  the  SAS.  This  defines  sequentially 
executed  operational  steps  for  each  function  within  the  system . 
This  PDL  can  then  be  used  to  generate  code. 

2.  System  prototyping  and  analysis.  With  the  association  of  a  PDL 
with  each  SAS  element,  system  prototyping  becomes  merely  the 
execution  of  the  PDL  (or  code  generated  from  the  PDL)  based  on 
the  signal  paths  and  system  hierarchy  defined  in  the  SOS  and  IDS. 

3.  Bus  loading  analysis.  As  bus  definitions  are  added  through  the 
use  of  the  IDS.  bus  loading  analysis  packages  can  Se  developed  for 
the  different  buses  to  aid  in  developing  the  interfaces  within 
avionics  systems. 


17-8 


V.  Conclusion 

In  summary,  the  critical  requirements  of  advanced  avionic  system  desig^n 
are  overall  system  requirements,  contigfuration  item  requirements,  interface 
requirements,  and  design  process  management  requirements.  These 
requirements  can  be  met  through  the  design  process  of  abstract  requirements 
deflnition.  requirements/functional  decomposition,  functional  recomposition, 
and  detailed  interface  definition.  This  process  can  be  greatly  aided  by  com¬ 
puter  automation,  resulting  in  the  design  of  more  complex  avionics  systems  in 
far  leas  time  than  would  be  possible  using  older  tools. 
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DISCUSSION 


J.Nicol,  UK 

While  recognizing  the  p(»tcntial  of  “A.StT“  for  new  aircraft  system  design.  hi>w  relevant  wt>uld  it  he  in  a  retrolii 
situation  where  the  customer  stipulateN  not  tmly  the  requirement  but  also  the  hardware? 

Author's  Reply 

The  functional  requirements  decomposition  phase  of  system  design,  as  automated  by  "ASET."  requires  only  iliai 
functions  be  decomposed  to  the  point  where  each  function  resides  in  a  separate  box.  While  *' ASF-T'  supports  further 
decomposition,  it  docs  not  reepnre  if  Therefore,  the  engineer  need  only  decompose  requirements  to  sufficient  detail, 
define  the  prespecified  hardware  to  be  the  function  that  satisfies  titose  requirements,  and  then  define  that  function  to  be 
a  leaf-level  function. 
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RESUME 


L'ergonomie  psychosensorielle  des  cockpits  s'oriente  de  plus  en  plus  vers  des  applications  dynamiques 
interactives  et  non  limitees  a  1 ‘application  de  normes.  Le  but  est  de  mieux  repondre  aux  besoins  cognitifs 
du  pilote,  de  mieux  1‘aider  dans  sa  tache  reelle.  Les  systemes  informatiques  intelligents  sont  indispensa- 
bles  a  cette  evolution.  Deux  types  d'applications  sont  decrites  :  la  premiere  consiste,  en  disposant  de 
donnees  precises  sur  la  perception  visuelle,  a  modifier  I'image  source  pour  y  faciliter  la  vision  de  tel 
ou  te1  detail.  La  seconde  consiste  a  elaborer  un  outil  d'aide  au  pilotage  preservant  le  pilote  de  toutes  ses 

possibilites  d'intervention  et  de  decision  mais  minimisant  ses  defauts  (fautes  d'inattention,  routines _ ) 

Un  modele  operateur  obtenu  par  mise  a  plat  de  1 'expertise  d'un  pilote  de  combat  a  ete  programme  dans  ce 
cadre  et  sert  a  etablir  la  faisabilite  du  projet. 


ABSTRACT 

Psychosensory  cockpit  ergonomics  consists  in  a  pluridisciplinary  approach,  focused,  we  believe,  on  global  consideration  of 
man-machine  interface  issues.  Knowledge  supplied  by  each  research  field  (sensory  physiology,  cognitive  psychology,  design  of 
intelligent  systems)  is  used  in  a  very  concrete  apprc^ch.  taking  into  consideration  aviation  requirements  and  technological 
advances. 

Intelligent  computer  systems  (“intelligent’*  should  be  preferred  to  “expert”)  are  ergonomics  systems  since  they  adapt  the 
rigidity  of  current  data  processing  systems  to  man-  and  situation-related  variabilities. 

To  build  such  systems,  certain  prerequisites  have  to  be  met; 

—  know  exactly  the  task  performed  by  the  user  (set  of  rules) 

—  know  exactly  transfer  functions  of  sensory  organs, 

—  be  able  to  define  exactly  physical  stimulations. 

Based  upon  this  knowledge,  the  system  can  follow  the  mission  as  a  function  of  its  real  course  and  pilot’s  strategies. 

Ergonomics  goals  can  be  listed  in  a  hierarchy: 

-self-operating  transparent  system  providing  protection  to  man  machine  couple. 

—  transparent  system,  modifying  psychophysical  properties  of  displayed  data  to  achieve  best  possible  adaptation  to  sensory 
capabilities, 

—  consultant  system  for  solving  problem  situations. 

These  various  themes  are  discussed,  using  examples  from  work  done  in  our  department,  which  demonstrate  the  value  of  this 
approach. 


INTRODUCTION 


L'ergonomie  psychosensorielle  des  cockpits  a  beaucoup  progress^  depuis  la  celebre  enquete  de  FITTS 
&  JONES  (1947)  mais  il  s'agit  toujours  dans  son  objet  scientifique  de  miniraiser  Ics  probleraes  poses  par 
1 'interface  entre  deux  modes  de  fonctlonnement  differents  :  celui  de  Thomme  et  celui  des  machines.  Comme 
I'hotnme  est  le  directeur  de  ce  couple,  l'ergonomie  vise  a  modifier  I'interface  afin  de  contraindre  le  moins 
possible  ce  partenaire  humain  a  perdre  de  I'energie  et  du  temps  dans  la  difficulte  de  communiquer  (  done 

de  reserver  ses  ressources  a  la  tache  elle-meme).  L'ergonomie  psychosensorielle  concerne  traditionnel lement 
I'adaptation  des  sorties  de  la  machine  aux  caracteristiques  des  entrees  sensorielles  de  I'operateur.  Ainsi 
en  va-t-il  des  regies  de  choix  de  tallle  de  caracteres,  de  couleurs,  de  contrastes,  plus  recemment  de  posi¬ 
tion  des  visual isattohS  dans  le  cockpit.  Des  normes  Internationales  de  standardisation  sont  souvent  dispo- 
nibles  et  cette  ergonomie  statique  s'appuie  solidement  sur  un  large  "base"  de  connaissances  th^oriques 
acquisB  par  la  psychophysique.  A  ce  jour,  les  resultats  sont  deja  grands  et  il  est  devenu  difficile  sition 
impossible  de  concevoir  un  cockpit  sans  s'interesser  de  pres  a  ces  elements. 

Depuis  quelques  annees,  cette  ergonomie  psychosensorielle  a  franchi  un  nouveau  cap,  prenant  parfois 
1e  nom  d'ergonomie  cognitive.  Elle  voudrait  privilegier  maintenant  une  ada^.tation  de  I'interface  non  plus 
limitee  aux  seuls  aspects  statiques  de  la  communication  (normes  visuelles,  auditives,  tactiles...)  mais 
etendue  aux  aspects  dynamiques  de  la  prise  et  du  traiteroent  des  informations  ;  modifications  des  carac- 
teristiques  psychophysiques  sous  contraintes  aeronautiques  ;  besoins  informationnels,  raisonnements,  strate¬ 
gies  ....  En  un  mot,  e11e  voudrait  etre  plus  pres  de  la  tache  journaliere  du  pilote. 

Le  d§ve1oppement  parallele  des  techniques  informatiques  rend  possible  cet'e  prise  en  compte  dynamique. 
L'interface  possede  alors  une  certaine  souplesse  et  e’est  cette  souplesse  que  I'on  peut  qualifier  de  dou- 
blement  intelligente  :  par  sa  nature  technologique  faisant  appel  a  1 ' intel 1 igence  artificielle,  par  son  but 
mettant  en  jeu  I'id^e  de  flexibility  intelligente  des  afficheurs  en  fonction  des  besoins  de  I'usager. 


Ce  long  point  introductif  doit  inclure  la  position  originale  de  ce  concept  d'aide  inteUigente  dans 
les  cockpits  par  rapport  aux  memes  concepts  habltuelleinent  developpes  par  les  bureaux  ingenieurs  (en 
precisant  que  ces  conceptions,  loin  d'etre  exclusives  sont  complementaires). 

Rappelons  avec  6ISSERET  (1983)  qu'il  existe  deux  grandes  classes  de  systemes  d'assistances  :  ceux 
crees  pour  reroplacer  Voperateur  dans  certaines  taches  istrat^gie  de  1 ‘automatisation)  et  ceux  crees  pour 
etre  des  aides  interactives  a  I'op^rateur  (strategie  de  I'aide  personnalisee) .  La  demarche  des  ingenieurs 
se  situe  souvent  dans  la  premiere  perspective  ;  la  demarche  du  laboratoire  se  situe  fondamentalement  dans 
la  seconde  perspective.  Elle  s'organise  selon  deux  applications  essentielles  prenant  leur  source  dans  des 
concepts  emanant  pour  I'un  plutot  de  la  physiologie  sensorlelle,  pour  1 ‘autre  plutot  de  1a  psychologie 
cognitive  sans  qu'il  y  ait  (a  nouveau)  vraiment  d'exclusive  entre  ces  approches.  Voici  ces  deux  concepts 
qui  vont  organiser  le  plan  du  texte  : 

-  par  la  connaissance  des  modeles  perceptifs,  il  est  possible  de  concevoir  un  asservissement  temps 
reel  de  Vaffichage  (dans  ses  qualiles  psychophysiques)  afin  qu'il  facilite  a  Voperateur  le  prelevement 
et  le  traitement  des  informations.  Cette  possibilite  peut  s'etendre  a  la  possibilite  de  flexibilite  du 
contenu  informationnel  des  afficheurs  en  fonction  des  besoins. 

-  par  la  connaissance  des  modeles  mentaux  utilises  par  le  pilote  (raisonnements,  anticipations, 
coherences),  il  est  possible  d'aider  le  pilote  dans  la  gestion  et  la  surveillance  de  parametres  qui  ne  sont 
pas  directement  impliques  dans  le  cours  d'action.  Ce  concept  est  finalement  assez  proche  de  I'idee  de 
WIENER  et  CURRY  (1985)  de  pilotage  par  transparence-car  le  systeme  informatique  ne  se  manifeste  qu'aux  li- 
mites  du  domaine  de  securite  du  vol. 

Ces  deux  programmes  sont  en  cours  de  developpement  au  C.E.R.M.A..  lls  relevent  encore  pour  de  nom- 
breux  aspects  de  la  phase  de  recherche  car  ils  necessitent  la  construction  prealable  de  modeles  de 
fonctionnement  cognitifs  du  pilote  et  leurs  mise  en  jeu  dans  des  systemes  informatiques  de  maitrise  archi- 
tecturale  encore  delicate. 

I  -  HODELES  DE  LA  PERCEPTION  ET  FLEXIBILITE  DES  AFFICHEURS 

1.1.  Bases  thtoriques  : 

Deux  types  de  travaux  constituent  la  base  d'un  certain  modele  perceptif  fonctionnel. 

-  le  premier  cnncerne  la  modelisation  de  la  fonction  de  transfert  des  organes  sensoriels,  essentiel- 
lement  la  vision  dans  le  cadre  de  cette  etude. 

Tous  les  systemes  sensoriels  ne  sont  sensibles  qu'a  certaines  classes  de  stimulations  et  a  I'interieur 
de  ces  classes  a  seulement  une  partie  des  stimulations  possibles.  On  peut  etudier,  en  analogie  avec  la  fonc¬ 
tion  de  transmittaice  d'un  systeme  quelconque,  la  fonction  qui  deceit  au  mieux  le  filtre  impose  par  cet  organe 
sensoriel  aux  stimulations  du  monde  physique.  Une  telle  relation  est  appellee  "fonction  de  transfert"  de 
1 'organe  sensoriel  considere.  En  vision,  les  stimuli  sont  des  radiations  61ectromagn§tiques  ;  I'oeil  n'est 
sensible  qu'a  un  intervalle  etroit  de  valeurs  de  ces  radiations  :  le  spectre  visible  (400-760  nm).  A  Tinte- 
rieur  de  ce  spectre  visible,  la  fonction  de  transmittance  se  deceit  dansle  domaine  spatial  et  dans  le  domaine 
temporel.  CAMPBELL  et  GREEN  (1965)  ont  montr4  que  la  transmittance  du  systeme  visuel  dans  le  domaine  spatial 
est  caracterisee  par  une  fonction  de  sensibilite  aux  contrastes  spatiaux.  MENU  (1986)  a  precis^  la  valeur 
standard  de  cette  fonction  pour  les  trois  couleurs  fondamentales,  en  central  et  en  excentricit^  jusqu'a  40  . 
L'oeil  se  prSsente  comme  un  filtre  passe  bande  haut  et  passe  bande  bas  (figures  1  ). 

Cette  fonction  se  modifle  sous  I'effet  de  facteurs  d*  agressions  a§ronautiques.  L'hypoxie  a  ete  le 
premier  facteur  teste.  13  sujets  jeunes  ont  participe  a  une  experimentation  de  recueil  des  FSC  polychromes 
a  plusieurs  niveaux  d'hypoxie  correspondant  a  des  altitudes  simuUes  en  caisson  a  depression  de  3.500,  4.500 
et  5.500  m.  (F.S.C.  :  Fonction  de  Sensibilite  aux  Contrastes.  F.S.  r  Frequences  Spatiales) 

L'hypoxie  modifie  les  seuils  des  differentes  frequences  spatiales  en  fonction  des  3  couleurs  primaires 
testees.  Les  seuils  des  hautes  frequences  spatiales  en  bleu  sont  les  premiers  modifies.  L'atteinte  est 
d'autant  plus  grande  que  I'altitude  est  elev^e  et  elle  gagne  les  F.S.  moyennes.  Les  seuils  des  F.S.  basses 
sont  les  mieux  conserves.  Pour  le  rouge  et  le  vert  les  seuils  sont  moins  perturbes  surtout  pour  les  F.S. 
elevees.  Le  vert  est  la  couleur  dont  les  seuils  sont  les  moins  modifies.  MENU  (1986)  a  pu  etablir  la  banque 
de  donnees  permettant  d'esquisser  un  modele  fiable  d'alteration  pour  cette  agression. 

Des  resultats  comparables  sont  egalement  acquis  en  ce  qui  concerne  1 'agression  lumineuse  (intensite 
lumineuse,  taille  du  champ  de  stimulation), 

Les  travaux  se  poursuivent  par  centre  au  C.E.R.M.A.  pour  etablir  1a  meme  banque  de  donnees  pour  les 
accelerations  et  les  vibrations. 

-  la  seconde  concerne  les  etapes  ulterieures  de  codage  de  1 'information.  Au-dela  du  premier  filtrage, 
des  resultats  tre^  importants  ont  ete  obtenus  en  ce  qui  concerne  la  vitesse  de  transmission  des  informations 
en  fonction  de  la  frequence  spatiale  sous  laquelle  elles  sont  presentees.  Les  details  les  plus  larges 
necessitent  les  temps  de  transmission  les  plus  courts.  Deux  systemes  anatomiques  et  neurophysiologiques 
differencies  sont  responsables  de  cet  ecart  :  les  voies  des  cellules  ganglionnaires  de  type  X  et  des  cellu¬ 
les  ganglionnaires  de  type  Y.  Les  cellules  de  type  X  ont  des  champs  r§cepteurs  beaucoup  plus  petits  que  ceux 
des  cellules  Y,  leurs  champs  dendritiques  sont  limites.  La  vitesse  de  conduction  des  influx  nerveux  dans 

les  axones  est  plus  lente  pour  les  cellules  de  type  X  par  rapport  aux  cellules  de  type  Y.  Les  cellules  de 
type  X  correspondent  S  des  photorecepteurs  situes  dans  la  zone  de  vision  centrale.  Les  cellules  Y  corres¬ 
pondent  a  des  photorecepteurs  peripheriques. 

Considerant  cette  theorie  psychophysique  des  canaux,  l.a  perception  des  gros  details  au  detriment  de 
details  plus  fins  s'imposerait  au  sujet  du  seut  fait  qu'il  s’agit  de  la  premiere  facette  de  I'image  source 
dlsponible  pour  les  centres  superieurs.  O'autres  theories  concurrentes,  notamment  derivees  des  themes 
Gestaltistes,  peuvent  rendre  compte  de  cette  preference  globale  sur  1 'analyse  fine. 
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Ainsi,  consld^rant  ces  deux  approches  (fonctlon  de  transfert  de  I'organe  sensoriel  et  roodeles  de  vitesse 
de  transmission  aux  centres  nerveux  sup4r1eurs)  I'^quipe  progresse  dans  la  construction  d'un  modele  des 
premiers  stades  de  la  perception  applicable  plus  direct^nent  au  concept  d'aide  intelligente. 

1.2.  Un  certain  aoddle  de  la  perception  et  les  aides  Intelllgentes  en  adronautique  :  1e  projet 
ERGO'ZNAGE. 

Les  connaissances  actuelles  ne  permettent  pas  d'avoir  1'ambitlon  de  dresser  un  modele  complet  et  fonc- 
tionnel  de  la  perception  visuelle  partant  d'un  stimulus  physique  complexe  et  arrivant  a  une  .interpretation 
valide  dans  1e  contexte.  Ld  n'est  pas  I'ambitlon  de  requipe  ni  du  modele. 

Cette  modeiisation  de  certaines  facettes  des  premiers  stades  de  la  perception  est  a  beaucoup  d'egards 
naive  car  trop  Incomplete.  Mais  cette  simplicite  est  d'un  autre  cote  un  gage  de  fonctionnalite  pour  des  aides 
dont  I'ainbition  est  limitee.  Void  1e  princIpe  retenu  pour  les  2  systemes  d'etudes. 

1.2.1.  -  le  premier  projet  consiste  -  partant  des  caracteristiques  physiques  d'une  source  primaire 

et  complexe  -  a  en  deriver  une  ou  plusieurs  images  secondes  correspondent  a  des  etapes  de  filtrage  et  d'inte- 
gration  que  Ton  peut  supposer  etre  -  grace  au  modele  -  celle  dont  dispose  le  Systeme  Nerveux  Central. 

L'aide  se  manifeste  dans  le  systeme  par  cette  capacite  a  reproduire  un  certain  nombre  d'etapes  senso- 
rielles  afin  d'orienter  la  perception  vers  telle  ou  telle  facette  de  la  r^alite  que.  spontan§ment,  le  filtre 
perceptif  avait  masque  ou  peu  favoris^. 

L'application  choisie  concerne  les  photo-interpretateurs  d'images  satellites,  mais  le  principe  d’une 
telle  aide  peut  etre  appliquS  aux  visualisations  du  monde  exterieur  pr§sentes  dans  les  cockpits.  Cette  pers¬ 
pective  est  d'ailleurs  envlsag^e  a  plus  long  terme. 

Dans  ce  cadre,  le  programme  de  recherche  debute  actuellement  sur  3  axes  : 

-  Psychophysique  :  en  recherchant  par  voie  experimentale  quels  filtrages  sont  evocateurs  d'un  contenu 
non  Evident  en  premilre  lecture,  le  paradigme  choisi  est  celui  du  test  de  GOTTSCHALOH  sur  les  figures  em- 
brouillfies.  Ce  test  s'inscrit  dans  la  probl6matique  des  styles  cognitifs  et  plus  particul ierement  de  la 
dSpendance-indSpendance  a  regard  du  champ  (WITKIN,1978} .  Les  sujets  d§penddnts  du  champs  ont  du  mal  a 
analyser  finement  et  analytiquement  une  image.  On  utilise  ce  constat  pour  determiner  differents  filtrages 
des  images  sources  afin  de  faciliter  la  perception  des  details  chez  ces  sujets.  Ces  filtrages  pour- 
raient  par  la  suite  etre  reconduits  et  testes  sur  des  images  complexes  de  photographies  aeriennes. 

'  Psychologique  :  en  recherchant  chez  les  professionnels  de  la  photo-interpr§tation  quel les  regies  de 
lecture  ils  acquierent  pendant  leur  formation  (il  s'agit  ici  de  regies  de  lecture  au  sens  exploration  de 
I'image  et  non  au  sens  de  I'interprgtation  fine  d'un  objet  donn^). 

'  Informatlque  :  en  recherchant  les  algorithmes  d'analyses  en  termes  de  contrasted  spatiaux  des  images 
complexes  et  surtout  en  recherchant  les  diffirentes  possibilit^s  de  filtrage,  recomposition  de  I’image  ainsi 
que  rintdgration  oonptdte  de  rdgles  de  production  destinies  a  conserver  une  s^mantique  a  I’image. 

1.2.2.  -  le  second  projet  est  plus  directement  appliqu§  a  I’Aide  Intelligente  au  pilotage  :  il  s’agit 
de  piloter  les  afficheurs  afin  qu'ils  modifient,  en  paralldle  aux  capacites  perceptives  et  dans  les  limites 
compatibles  avec  une  conservation  de  1 'information,  les  caracteristiques  physiques  des  stimulations  (en 
termes  de  frequence  spatiale,  contrastes)  lors  des  diverses  agressions  aeronautiques. 

La  faisabilite  de  ce  projet  necessite  I'obtention  premiere  de  banques  de  donnees  sur  les  modifications 
perceptives  lors  d'agresslons  aeronautiques  {cette  etape  est  en  cours,  les  etapes  de  faisabilite  technologique 
ne  seront  pas  envisagees  avant  deux  ans). 

II  -  MOOELES  NENTAUX  ET  AIDES  INTEUIGENTES 


L'operateur  est  par  essence  un  etre  raisonnant  et  anticipant.  Il  dispose  de  connaissances  que  Ton  peut 
appeler  declaratives  ou  cognitives  sur  son  tableau  de  bord,  sur  sa  mission.  Il  dispose  aussi  de  connaissances 
plus  dynamiques,  plus  fonctionnel les  groupees  de  fagon  circonstanciel les,  que  certains  appeleront  represen¬ 
tations  mentales  operatives  (0CHANINE,1981)  ou  fonctionnel les  (LEPLAT,1985)  et  d'autrcs  modeles  mentaux 
(NORMAN, 1983). 

L'ensemble  de  ces  connaissances  peut  etre  lui-m^  designe  par  le  terme  de  "competences  sur  le  domaine" 
(de  M0NTM0LLIN,1983)  ou  encore  par  celui  d'expertise  (Acole  de  Carnegie  Mellon,  1975). 

Le  role  des  modeles  mentaux  est  de  guider  et  de  reguler  les  activites,  d’indiquer  ce  qu'il  y  a  a  faire. 
On  parle  dans  ce  cas  de  connaissances  procedurales.  Sans  entrer  dans  la  ceiebre  controverse  declaratif/proce- 
dural  (voir  par  exemple  WINOGRAO,  1981),  il  est  clair  que  Ton  salt  peu  de  choses  sur  les  raisonnements  reels 
de  l'operateur. 

Les  acquis  e  ce  jour  sont  souvent  centres  sur  la  resolution  de  probiemes  ;  les  applications  en  tant 
qu'aides  intelllgentes  interactives  sont  compietement  tournees  vers  cette  situatioi. 

La  situation  de  probleme  est  ici  classiqueroent  definie  (NEWELL  S  SIMON, 1959^  comme  une  situation  pour 
laquelle  existe  un  etat  Initial,  un  etat  final  a  atteindre,  des  operateurs  de  transformation  d'etat,  et 
aucune  solution  connue  pour  passer  d'un  etat  a  I'autre.  Les  modeiisations  informatiques  de  la  resolution 
de  probiemes  simples,  tel  que  le  jeu  de  la  "tour  de  hanoT",  sont  maintenant  nombreuses.  On  citera  la  plus 
classique  :  General  problem  Solver  de  NEWELL  et  ALL.  (1959)  et  quelques  derives  introduisant  les  capacites 
de  generalisation  et  de  ralsonnement  par  analogle  (CARBONELL,  SAGE  2,  UNDERSTAND...). 

Ces  modeles  informatiques  ont  connu  de  nonrt>reuses  tentatives  d'appHcations  aux  situations  de  controle 
de  processus,  notamment  dans  les  industries  nucieaires.  Un  courant  de  recherche  tres  productif  s’interesse 
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ainsi  aux  situations  incidentielles  :  resolution  d'incidents  graves  (par  exemple  RASMUSSEN  (1985)  dans 
]' Industrie  nucleaire,  SENACH  { 1986)  dans  le  contrdle  du  trafic  du  metro...).  Les  methodes  employees  pour 
recueillir  la  base  de  faits  necessaire  au  modele  sont  soit  I'observation  sur  site  reel  ou  simule  (analyse 
de  protocoles),  soit  des  techniques  de  laboratoires  (informations  a  la  demande). 

L'aide  intelligente  est  souvent  dans  ce  cas  un  systeme  expert  capable,  en  regroupant  les  evenements 
d'une  certaine  fagon,  de  proposer  des  conclusions  interpretatives  sur  la  cause  (en  tout  cas,  au  moins  des 
orientations) . 

L ‘etude  systematique  des  accidents  aeriens  et  les  observations  sur  le  terrain  nous  ont  amene  (AMALBERTI, 
1986)  a  une  reflexion  un  peu  differente  de  ces  travaux. 

En  effet  un  grand  nombre  d' accidents  se  produisent  non  parce  que  I'operateur  n‘a  pas  su  resoudre  une 
situation  problematique  mais  parce  qu‘il  n'a  pas  su  ou  pas  compris  qu'il  etait  dans  une  situation  proble- 
matique  :  la  premiere  difficulte  a  resoudre  ure  situation  a  problemes  c'est  de  savoir  qu'il  s'agit  d'un 
probleme. 

Exemple  :  le  boeing  des  Korean  Air  Lines  s'ecarte  de  plusieurs  centaines  de  kilometres  de  sa  trajectoire 
sans  que  "I  Tqui page  pergoive  cet  ecart  ...  le  probleme  n'a  pas  ete  per^u. 

Dans  tous  les  cas,  l'aide  qui  aurait  ete  precieuse  consisterait  a  forcer  I'equipage  a  changer  de 
representation  mentale,  a  reconsiderer  la  situation  ou  a  ne  pas  focaliser  son  champ  perceptif  a  quelques 
informations  seulement. 

C'est  done  dans  cette  voie  de  developpement  d'aides  Intel ligentes  que  le  laboratoire  s'est  engage. 

Le  principe  du  systeme  propose  est  le  suivant  . 

Un  module  informatique  travaille  en  paralleleau  pilote  ;  11  a  pour  charge  une  surveillance  globale  de 
la  situation  a  court  et  moyen  terme.  II  evalue  notamment  les  ecarts  entre  la  valeur  instantannee  de  certains 
parametres,  la  valeur  de  ces  memes  parametres  a  moyen  terme  compte  tenu  du  deroulement  du  vol,  et  une  certaine 
valeur  acceptable  toujours  de  ces  memes  parametres  a  court  et  moyen  terme. 

Son  analyse  est  fondee  sur  le  recueil  et  1 ' interpretation  des  actions  du  pilote  sur  I'interface,  la  con- 
naissance  des  strategies  et  des  heuristiques  les  plus  importantes  n^cessaires  a  la  mission  ainsi  que  la  connais* 
sance  d'un  deroulement  forme]  de  la  meme  mission  et  de  ses  variantes  les  plus  frequentes. 

Ce  systeme  devrait  etre  capable  a  partir  d’un  calcul  de  coherence  de  deceler  les  ecarts  et  de  les  signaler 
au  pilote.  Pour  etre  sur  que  ce  dernier  percevra  cette  information  d'alerte,  ces  informations  peuvent  etre 
affich^es  en  lieu  et  place  d'autres  informations  que  le  module  suppose,  compte  tenu  de  la  strategie  detect^e, 
que  I'operateur  preleve  regulierement. 

Ce  type  d'aide  est  completement  oriente  vers  la  security  des  vols  a  court  et  moyen  terme.  II  s'agit  de 
minimiser  les  consequences  de  certains  inconv^nients  des  comportements  cognitifs  humains  (inattentions,  rou¬ 
tines,  fixity  contextuelle  des  representations  mentales  ...). 

La  base  du  systeme  interactif  est  la  partie  module  de  detection  de  contexte,  module  de  detection  de  stra¬ 
tegies.  Le  projet  "AIDE"  developpe  au  C.E.ft.M.A.  vise  o  etablir  la  faisabilite  d’un  tel  module  sur  un  cas 
exemple,  celui  de  la  penetration  tres  basse  altitude  sans  visibllite.  11  integre  a  plusieurs  niveaux  I'ergo- 
nomie  cognitive  et  les  systemes  informatiques  Intel ligents. 

Ce  projet,  conduit  sur  plusieurs  annees,  comprend  plusieurs  etapes  : 


1  -  mise  a  plat  de  I'expertise  d’un  pilote  professionnel  affecte  a  ce  type  de  mission, 

2  -  modelisation  informatique  de  cette  expertise  et  generalisation  a  toutes  les  situations  de  la  tauhe  et 

a  tous  les  operateurs, 

3  -  realisation  proprement  dite  du  module  intelligent  pour  ce  cas  exemple. 

La  phase  1  est  realisee,  la  phase  2  est  en  cours. 


Les  methodes  utilisees  pour  recueillir  I'expertise  sont  basees  sur  une  analyse  de  la  tache  formelle,  tres 
fine,  des  techniques  de  questionnement  de  1 'expert  et  1 'observation  sur  le  terrain  de  vols  reels  avec  cet 
expert,  AMALBERTI  et  VALOT  (1985)  i  AMALBERTI  et  al.  (1986). 

La  formation  s'articule  autour  de  la  notion  de  plans,  schemas  et  scripts.  Elle  inclut  aussi  deux  elements 
plus  originaux  que  sont  "les  regies  d'univers",  connaissances  capables  de  moduler,  inhiber  ou  favoriser  des 
strategies  et  les  connaissances  sur  I'interface  encore  appelees  "connaissances  semiologiques"  qui  sont  les 
atonies  elementaires  du  savoir  necessaire  a  1 'execution  des  plans,  sche.  as  et  scripts  (figure?  ). 

Les  plans  correspondent  aux  differentes  variantes  globales  de  la  mission  etudiee. 

Les  schemas  sont  des  groupenwnts  de  connaissances  permettant  1 'execution  de  sous  parties  du  plan.  Pour 
chaque  sous  partie  (e.g.  navigation  sur  route  pr^paree),  I'expertise  rend  cdmpte  d'  "un  schema  prototypique" 
ou  schema  de  reference.  Ce  dernier  est  construit  a  partir  de  la  synthese  des  entretiens  conduits  avec  le 
pilote  expert,  C'est  un  "exemplaire"  qui  n'a  jamais  ete  reellement  observe  mais  qui  represente  au  mieux  les 


actions  de  ce  segment.  D'autres  variantes  de  ce  schema  (incluant  celles  rdellement  observees  sur  1e  terrain) 
sont  disponibles  dans  I'expertise.  Elies  permettent  de  rooduler  le  schema  prototypique  en  fonction  des  contrain- 
tes  extSrieures. 

Les  scripts  sont  egalement  des  groupements  de  connaissances  elementaires  destines  a  I'ex^cution  sur  le 
systeme  d'actions  ou  de  series  d'actions  d^crites  dans  les  schemas.  Tous  les  scripts  sont  en  un  certain  sens 
prototypiques  :  ils  sont  relativement  rigides  (leurs  d^ours  est  peu  influence  par  les  evenements)  ;  ils 
peuvent  s'appliquer  a  une  tn§me  situation  et  poss^der  le  meme  but  mais  leur  contenu  reste  tres  different  de 
I’un  a  I'autre.  Le  pilote  en  connait  plusieurs  et  se  sert  de  l‘un  ou  de  I'autre  suivant  le  contexte.  C'est 
pourquoi  le  choix  des  scripts  est  effect! vement  d#crit  dans  1 'expertise  par  un  systeme  de  regies  de  produc¬ 
tion. 


Les  connaissances  "sSmiologiques"  sont  assimllables  a  des  connaissances  declaratives.  Elies  font  cor- 
respondre  a  un  indicateur  du  tableau  de  bord  une  signification  particuliere  avec  des  valeurs  cles. 

L'adaptation  a  tous  les  pilotes  et  toutes  les  situations  des  aides  intelligentes  les  plus  sophistiquees 
pose  a  propos  de  cette  expertise  les  deux  questions  suivantes  : 


'  peut-on  completer  surtout  pour  les  domaines  de  vol  inhabituels  (capacite  a  changer  de  strategies, 
strategies  de  sauvegarde).  Les  techniques  d'entretiens  et  de  simulation  ne  suffisent  plus  pour  rechercher 
ces  connaissances. 

-  est-elle  stable  ou  quasi  stable  entre  professionnels  pilotes  d’un  meme  avion  et  d'experience  aero- 
nautique  comparable  ? 

Le  systeme  AIDE  est  destine,  dans  un  premier  temps,  a  completer  1 'expertise  et  a  repondre  a  ces 
questions  sur  la  generalisation.  II  s'agit  d'une  modelisation  informatique  de  I'expertise  deja  possedee, 
capable  d'interactions  temps  reel  avec  un  modele  informatique  avion. 

AIDE  simule  la  conduite  de  processus  du  pilote.  II  se  caracterise  par  sa  capacity  a  justifier  sur  son 
module  sortie  (ecran  cathodique)  ses  actions,  les  lieux  ou  il  preleve  I'information  (zoom  sur  la  zone  du 
tableau  de  bord  consultee)  et  ses  raisonnements  (fenetre  d'expl ications  en  langage  nature!  et  affichage  des 
buts  et  sous  buts  poursuivis). 

Le  processus  d'enrichissement  et  de  generalisation  repose  sur  la  confrontation  de  ce  fonctionnement 
"transparent"  du  modele  avec  les  pilotes  de  ce  type  d'avion.  AIDE  peut  etre  interrompu  a  tout  moment  et 
dispose  de  capacit^s  de  playback.  Son  architecture  permet  egalement  I’insertion  alsee  de  nouveaux  plans, 
schemas,  scripts  et  autres  connaissances. 


2.1.  Architecture  et  fonctionnement  du  modele 


2.1.1.  Archi tecture 


La  structure  informatique  a  et§  61aboree  pour  refUter  au  mieux  "la  structure  cognitive"  a  laquelle 
aboutit  I'expertise. 

La  mission  est  d^composee  en  plusieurs  phases  pratiquement  autonome..  Chaque  phase  est  un  objet  {au 
sens  des  langages  orient$s  objet)  avec  une  structure  interne  sp^cifique  dont  nous  allons  detainer  un  exam¬ 
ple  (Cf.  schema). 

La  partie  centrale  est  le  moniteur  communication  qui  centralise  les  flux  d' informations  et  de  decisions 
s'echangeant  dans  I'objet.  II  joue  le  role  d'un  "blackboard’’.  Le  mcniteur  schema  contient  la  liste  des  scripts 
a  accomplir  par  le  module  dans  le  cadre  de  I’objet  ainsi  que  leurs  specifications.  Les  scripts  proprement 
dits  sont  dans  le  dictionnaire  de  scripts. 


Un  moniteur  "evenements",  un  moniteur  "interruptions"  et  un  moniteur  ’’temps"  sont  relies  au  moniteur 
"communication"  et  interviennent  dans  les  mecanismes  d'autoadaptation  aux  exigences  de  la  situation. 


Fonctionnement  (figure  3) 


En  fonctionnement  normal,  le  moniteur  "conriunications"donne  la  main  au  moniteur  "schema"  initialise 
avec  un  schema  prototypique.  Ce  dernier  deroule  sa  suite  de  scripts  et  alimente  la  base  de  faits  courants. 

Dans  le  cas  d'une  reponse  non  attendue  a  un  script,  d’une  panne,  d'une  interruption  ou  d'une  alarme, 
la  main  revient  au  moniteur  "communications"  qui  declenche  le  moniteur  "evenements"  ou  le  moniteur 
"interruptions/  Ces  moniteurs  disposent  d'une  base  de  regies  specifiques qui  travaille  sur  la  base  de  faits 
courants  et  decide  du  choix  d'un  ou  plusieurs  scripts  de  traitement  de  1 'incident  a  inserer  dans  le  moniteur 
schema. 

Le  moniteur  "temps"  est  ensuite  appeie  et  a  I'aide  de  regies  egalement  specifiques  refietant  le  com- 
portement  du  pilote  face  h  la  pression  temporelle  valide  le  nouveau  schema  et  decide  des  caracteristiques 
temporelles  des  scripts  (duree,  ordre  de  succession  et  meme  suppression  de  certains  scripts). 


IS-6 


AIDE  est  ainsi  capable  de  s'autoadapter  a  un  grand  nombre  dc-  situations.  Sa  strategie  consiste  a 
conserver  la  validite  du  schema  prototypique,  aroenage  plus  ou  moins  ^ortement  selon  i ‘incident,  aussi  long- 
temps  que  possible.  II  compilera  les  procedures,  11  sautera  les  etapes,  11  controlera  moins  de  pararoetres 
dans  ce  seul  but  de  pouvoir  effectuer  ce  schema  plus  les  corrections  de  1 ‘incident  dans  1e  temps  initiale- 
ment  Imparti. 


Ce  mode  de  fonctionnement  nous  parait  simuler  correctement  certains  aspects  du  fonctionnement  de  la 
representation  mentale  humaine.  Cette  strategie  a  d'ailleurs  quelques  avantages  puisqu'elle  economise  une 
revision  complete  ae  la  situation  (couteuse  en  temps  et  en  complexite)  avec  remise  en  cause  du  scnema  voire 
du  plan.  AIDE  est  cependant  capable,  si  aucune  alternative  ne  s’offre  a  lui,  de  faire  cette  revision  en 
situation  incidentel le. 


En  relation  avec  ce  programme  purement  operateur  tourne  un  modele  avion  qui  sert  a  simuler  les  evolutions 
de  1 'avion  et  une  interface  graphique  pilotee  par  le  modele  operateur  et  qui  presente  I’etat  de  la  planche  de 
bord  de  I'appareil.  Selon  les  specificites  de  I'objet  et  du  script  en  cours,  apparaissent  des  zooms  sur  la 
partie  du  moniteur  concernee  par  les  prises  d' informations  ou  les  actions.  En  parallele  defilent  dans  une 
fenetre  les  justifications  des  strategies  et  des  scripts  employes  (figure  4). 

2.2.  Experiaentatlon 


Le  protocole  de  travail  avec  les  pilotes  prevoit  deux  types  de  scenarios  a  juger  : 

-  les  premiers  sont  des  variantes  du  scenario  prototypique  de  la  mission  dont  on  salt  que  AIDE  est 
capable  de  resoudre  en  reproduisant  des  heuristiques  observees  chez  1 ’expert. 


-  les  seconds  sont  des  variantes  si  contraintes  que  AIDE  ne  peut  les  resoudre  par  une  simple  appli¬ 
cation  des  heuristiques  qu’il  connait.  Le  modele  propose  alors  des  solutions  plus  ou  moins  valines. 


Chaque  pilote  pr&pare  chaque  scenario  comme  sMl  allait  executer  la  mission  afin  de  disposer  des 
connaissances  factuelles  de  contexts  et  mieux  jugrr  de  la  qualite  des  solutions  proposees  par  le  modele. 


11  peut  arreter  a  tout  moment  le  processus,  revenir  en  arriere,  verbaliser  des  corrections  ou  des 
ecarts  de  fd<;on  de  faire  ;  toutes  les  seances  sont  videoscopees  et  analysees  secondairement  afin  d'incor- 
porer  au  modele  les  nouvelles  connaissances  ou  strategies. 


A  ce  jour,  AIDE  est  on  cours  de  programmaLion.  li  devrait  etre  acheve  en  fin  d’ete  1987  et  les  expe¬ 
rimentations  sont  prevues  a  cette  date.  La  construction  d'un  module  d’analyse  contextuelle  applicable  a  cet 
example  est  envisage  pour  1989. 


Ill  -  CONCLUSION 


Oepuis  quelques  annee:,  I'avenir  des  recherches  en  ergonomie  psychosensoriel le  passe  par  1 'utilisation 
de  syst^mes  informatiques  Intel  1  igents.  Nous  avons  essay^  dans  ce  texte  de  montrer,  a  par‘:ir  d'exemples 
developpes  au  C.E.R.M.A.,  quelques  pistes  a  cette  evolution  future  des  cockpits  qui  deviendront  a  la  fois 
plus  flexibles  et  plus  personnalises  dans  leurs  presentations.  Le  plus  grand  benefice  de  ces  systemes  sera 
finalement  de  combattre  les  defauts  ou  les  limites  psychosensoriel les  de  1 'operateur  tout  en  lui  preservant 
ses  qualites  de  decideur  et  d'acteur  a  tous  les  niveaux  du  controle  de  processus.  Tout  systeme  participant 
a  cette  transformation  merite  le  nom  d'ergonomique. 


Une  autre  forme  d'ergonomie  consiste  et  consistera  sans  doute  a  automatiser,  a  decharger  le  pilote  de 
taches  de  plus  en  plus  complexes.  Cette  voie  reduit  la  charge  de  travail  mais  elle  exclut  aussi  d'une 
certaine  fagon  1 ‘operateur  d’un  plus  ou  moins  grand  nombre  d'actions.  Les  etudes  doivent  se  poursuivre 
avec  assiduite  pour  la  controler  et  I'appliquer  a  bon  escient,  c'est  a  dire  justement  de  fa^on  ergonomique. 
Ainsi,  une  meilleure  connaissance  des  processus  cognitifs  du  pilote  permettra,  meme  dans  cette  voie  de 
I’automatisation,  de  faire  fonctionner  les  machines  avec  une  intelligence  "plus  humaine".  L'operateur  pourra 
alors  reellement  comprendre  son  partenaire  machine,  le  diriger  et  "reprendre  la  main"  a  bon  escient. 
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FISUBE  1 

EVOLUTION  DC  LA  FONCTION  NOTCNNE  DC  SCNSIBILITC  AUX  CONmASTCS  SPATIAUX  POUR  LA  COULCUR  BLCU 
(40  cd/tf )  en  FONCTION  OC  L'CXCCNTRICITC  DC  PRESENTATION  DC  RCSCAUX  VERTICAUX 
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EXEMPLE  DE  WISE  A  PLAT  DE  fEXKRTlSE  DU  PILOTE  DE  COMBAT. 
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MOOELE  INFORMATIQUE  :  les  differentes  parties  d'un  objet  avec  leurs  sp§c1f1c1t6s  et  leurs  Interactions 

Les  fleches  1  et  1'  indiquent  le  deroulement  d'un  schema  sans  evenement  fortuit.  Les  fleches  2  a  10, 

A  et  B  indiquent  la  maniere  dont  est  geree  I'adaptation  du  schema  aux  contraintes  ext^rieures. 


HONITEUR  INTERRUPTIONS 


-  NNioIre  des  evcrwents  rteents 

'  M6«K>ire  des  buts  poursulvis 

“  Justification  (en  langage  nature!) 
des  actions  aen^s  et  des  raison- 
neaents  en  cours. 


FIGURE  4 

SCHEW  DC  SORTIE  SUR  ECRAR  00  FORCTlORREICItT  00  NOOELE  IirORRATIQOE  DE  L'OPERATEOR. 

Ce  type  de  presentation  est  destine  a  servir  de  support  au  recuei t  complementaire  d'expertise 

aupres  des  pilotes. 


DISCUSSION 


J.Nicol,  UK 

Dots  the  research  completed  to  date  give  the  CERMA  team  confidence  in  the  coherence  of  pilot  mindset? 

Author's  Reply 

Yes.  we  are  confident  in  the  relative  stability  of  pilot  mindset.  On  one  hand,  pilots  obviously  are  human.  They  have 
opinions  and,  in  separate  conditions  from  real,  they  may  vary  their  comments  on  the  same  situation,  depending  on  the 
context  and  interlocutors. 

On  the  other  hand,  increasing  system  complexity  largely  reduces  the  real  variants  of  their  own  way  to  manage  systems. 
New  planes  are  more  and  more  procedural  in  nature.  Degrees  of  freedom  are  diminishing.  For  that  reason,  for  the  maiii 
heuristics  at  least,  we  are  confident  in  the  coherence  of  pilot  mindset. 


W.MelUno,  IT 

Which  tools  and  languages  did  you  use  in  formalizing  the  pilot  expertise? 

Author's  Reply 

We  used  VAX  station  GFX- 1 1  (DEC)  with  live  memory  extended  to  9  Models  and  LISP  language  in  formalizing  the 
pilot  expertise. 
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ADVANCED  DEVELOPMENT  OF  A  COCKPIT 
AUTOMATION 

DESIGN  SUPPORT  SYSTEM 


Philip  V.  Kulwicici 
Joe  W.  McDaniel,  PhD 
Lila  M.  Cuadagna,  2LC.  USAF 
AAMRL/HEX-CAT 

Wrlght-PatCerAon  AFB,  Ohio  45433-6373 
United  Statet  Air  Force 


SUMMARY 

Under  the  autplcei  of  the  United  Statei  Air  Force  Cockpit  Autonation  Technology 
(CAT)  advanced  developacnt  prograa,  a  highly  dlicipllned  and  structured  crew  system 
design  process  (along  with  Iti  supporting  dealgn  tools  and  technology)  Is  being 
developed  to  Improve  the  efficiency  and  effectiveness  by  which  advanced  cockpits  can  b.- 
fielded.  As  an  Initial  Inplenen ta t Ion  of  the  CAT  design  process,  a  Cockpit  Automation 
Design  Support  System  (CADSS)  la  being  developed  to  provide  a  computer-aided  design 
environment.  Including  the  software  design  tools  and  the  simulation  utilities  Chat  can 
facilitate  the  development  of  the  crew  system  In  synchrony  with  the  development  of  the 
avionics  and  weapon  system.  The  rationale  underlying  the  CADSS  will  be  described  In 
terms  of  the  system  components  which  Include  a  Designer's  Computer-Aided  Des-lgn  System 
(DCADS)  processor,  new  software  tools  and  a  breadboard  cockpit  simulator  which  are 
envisioned  to  complement,  but  not  replace,  existing  development  facilities.  This 
implementation  of  a  cockpit  design  support  system  la  described  In  relation  to  the 
overall  CAT  program  activities  and  schedule. 


INTRODUCTION  AND  BACKGROUND 

The  CAT  program  stems  from  a  management  recognition  of  the  Increasing  Importance 
of  the  crew  system  within  the  overall  avionics  and  weapon  system  design,  the  lack  of  a 
standard  process  for  development  In  Che  current  design  practice,  and  the  need  for  a 
systematic  design  process  having  traceability  and  an  audit  feature  to  help  avert  (but. 
If  necessary,  to  correct)  design  flaws  early  In  the  weapon  system  acquisition  cycle.  The 
CAT  design  process  Is  tightly  coupled  to  the  overall  weapon  system  development  and 
concentrates  on  satisfying  operational  mission  demands  and  aircrew  needs  In  an  Iterative 
manner,  with  a  formal  connectivity  among  engineering  analysis,  design  and  piloted 
slmulat Ion . 

Origins  for  the  CAT  project  date  to  I960,  at  which  time  the  United  States  Air 
Force  Systems  Command  (AFSC)  planned  for  a  new  crew  systems  technology  Initiative  to 
focus  on  Che  needs  of  combat  crews.  Prior  to  that  time,  those  needs  were  addressed  In 
other  programs,  but  were  sometimes  underemphasized  due  to  the  hardware  and  software 
complexities  of  emerging  systems.  Under  Che  leadership  of  the  Aerospace  Medical  Division 
(recently  renamed  the  Human  Systems  Division),  a  component  of  AFSC,  three  advanced 
development  projects  were  established  (see  Figure  1).  An  Advanced  Life  Support  Systems 
Project  was  activated  In  1983  to  provide  a  new  generation  of  aircrew  personal  protective 
equipment  (to  Include  new  flight  gear  for  altitude  and  acceleration  protection  and  for 
ocher  purposes).  In  1984,  an  Advanced  Crew  Escape  System  Technology  Project  began  to 
advance  ths  state-of-the-art  for  technologies  needed  Co  expand  the  escape  envelope 
associated  with  open  ejection  seats.  Also  Initiated  In  1984,  the  Cockpit  Automation 
Technology  (CAT)  Project  was  established  to  organize  and  advance  Che  process  for  crew 
system  design  (see  Figure  2). 

NEED  FOR  DESIGN  PROCESS  DEVELOPMENT 

The  CAT  project  Is  unique  In  that  It  concentrates  on  process  rather  than  aircraft 
components  or  point  designs.  The  need  for  Investment  In  design  process  could  be 
questioned.  In  view  of  today's  scarce  research  and  development  resources,  because  (after 
all)  we  have  designed  end  fielded  operstlonsl  systems  having  substantial  capability. 
However,  the  current  development  practice  has  led  to  a  situation  wherei  (1)  Important 
design  deficiencies  are  Identified  very  late  In  development  (this  leads  to  excessive 
reliance  on  expensive  changes  In  both  hardware  and  software),  (2)  the  weapon  eystem 
developnent  Itself  Is  a  lengthy  procees  (often  spanning  more  than  10  years),  (3)  the 
cost  and  complexity  necessary  for  advanced  weapon  systems  ars  continuing  management 
concerns,  (4)  the  systems  remain  in  operational  Inventory  (or  decades  and  undergo 
significant  configuration  upgrades,  and  (3)  significant  crew  system  operability  and 
workload  concerns  are  becoming  apparent  In  emerging  systems. 

In  ths  arena  of  cockpit  craw  systems,  the  emergence  of  digital  avionics,  with  its 
potentially  massive  amount  of  data  available  for  display  and  large  number  of  aircrew 
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control  Interaction*,  ralaea  new  development  challenges.  Today's  aircrew 
members,  particularly  In  fighter  systems,  must  monitor  and  control  a  myriad  of 
sophisticated  avionics  systems  and  weapons,  often  In  hazardous  flight  regimes,  with 
demanding  time  constraints.  In  concert  with  cooperative  aircraft  participating  In  Che 
same  mission,  and  under  potential  threat  attack.  Pilot  workload  Is  sometime*  excessive, 
partly  due  to  Che  need  for  sorting  through  encyclopaedic  quantities  of  data  (much  of 
which.  In  current  systems,  may  be  Irrelevant  to  the  task  at  hand)  to  glean  that  which  Is 
necessary  to  perform  the  Immediate  task.  The  consequence.  In  Che  modern  combat  arena, 
can  be  cask  "shedding"  (l.e.,  some  needed  tasks  are  not  performed)  or  loss  of  situation 
awareness  which,  once  lost,  nay  be  difficult  or  Impossible  to  regain.  This  occurs.  In 
the  authors'  opinion,  because  of  serious  limitations  In  the  crew  systen  design  process 
(as  It  Is  currently  applied;  see  Figure  1). 

Based  on  three  years  of  detailed  examination  of  both  development  needs  and  current 
practices  In  crew  systen  design/evaluation,  we  observe  that: 

(1)  There  Is  little  or  no  standardization  of  Che  current  crew  system  design 
process.  There  are  conpany-to-company  differences  In  design  q>rocess  and  Its  application; 
there  arc  sy s t em- to- sy s tern  differences  In  the  extent  of  management  oversight. 

(2)  There  Is  an  ove r- re  1 lane e  on  expert  opinion  In  crew  system  design  decisions, 
with  minimal  dependence  on  formal  analyses  and  truly  objective  tests. 

(3)  Often,  steps  are  "skipped*  and  shortcuts  are  taken  In  order  to  meet  schedule. 

(4)  There  Is  an  over- rel lance  on  Cine-consuming  manual  design  methods. 

In  this  regard,  Che  crew  system  design  community  appears  to  seriously  lag  other 
technical  disciplines  In  Che  field  of  design  automation. 

(3)  Crew  system  design  tends  to  be  emphasized  late  In  the  systen  acquisition 
process  with  other  related  design  constraints  already  fixed;  this  Inhibits  Che  trade-off 
of  crew  system  needs  with  ocher  subsystem  needs. 

(6)  Crew  system  design  guide  documents  are  outdated.  For  example,  according  to 
Smith  4  Hosier  (1986,  pp4-5),  "human  engineering  standard*  and  design  handbooks  have  In 
the  past  been  of  little  use  to  the  software  designer  ".  Often,  design  decisions  are  not 
recorded  and.  If  recorded,  they  are  not  easily  retrievable.  Crew  systen  design  "lessons 
learned"  are  not  effectively  distributed  to  new  system  developments. 

(7)  While  there  has  been  a  substantial  Increase  In  the  field  of  engineering  flight 
simulation,  crew  system  developers  have  been  relatively  slow  to  exploit  it*  potential. 
Objective  measures  to  evaluate  crew  system  performance  are  argumentative  (or  missing). 
Simulator  tests  may  not  employ  scientific  controls  and  they  often  focus  on  subjective 
preferences  for  proof-of-concept  rather  than  on  engineering  data  to  support  design 
trades  . 

(8)  Often,  high  fidelity  flight  simulators  are  not  directly  accessible  Co  crew 
system  developers;  tools  that  are  readily  accessible,  such  as  static  mock-ups  and 
simplified  part-task  design  aids,  tend  to  be  useful  more  for  f orm- f 1 1- f unc 1 1  on  studies 
than  for  understanding  pilot  Information  management  and  workload  as  they  relate  to  the 
crew  systen  operation  (yet  this  latter  design  area  Is  critical  for  mission  succos). 

(9)  Mission  requirements  established  for  air  vehicle  sizing  and  performance 
prediction  are  Insufficiently  detailed  for  crew  system  development. 

(10)  The  direct  Interrelationship  between  crew  system  development  activities  and 
other  related  weapon  system  development  activities  appears  to  be  poorly  understood, 
leading  to  an  Inefficient  generation  and  use  of  design  data;  the  extent  and  focus  of 
crew  system  development  varies  us  the  design  progresses  toward  deployment  of  the  weapon 
system. 


(11)  During  the  system  lifetime,  a  substantial  amount  of  design  change  Is 
Inevitable,  but  a  scheme  to  maintain  the  traceability  of  the  crew  station  design 
evolution  has  not  been  Implemented.  As  a  result,  change  decisions  can  be  based  upon 
unnecessarily  Incomplete  Information  which  can  aggravate  the  reintegration  problem. 

(12)  Although  attempt*  have  been  made  to  develop  computer-based  design  "tools", 
the  developments  have  been  somewhat  piecemeal  and  the  resulting  products  are  not 
generally  In  wide  use. 

OVERVIEW  OF  COCKPIT  AUTOMATION  TECHNOLOGY  PROJECT 

The  CAT  project  has  been  planned  and  organised  to  redress  the  above  concerns.  Use 
of  the  term  "automation"  In  the  project  title  confers  t.-.e  sxpectatlnn  that  automation 
technology  will  be  central  to  resolving  the  difficulties  that  must  be  resolved  In 
fielding  effective  combat  crew  systems.  This  project  develops  an  organltsd, 
methodological  crew  system  design  and  development  procsss;  It  applies  this  process  to  s 
specific  operational  mission  to  demonstrate  proof-of-eoncapt ;  It  develops  a 
computer-based  support  system  ss  s  design  snvtronnsnt  to  promets  design  process 
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efficiency*  Col 1 cc c t ve 1 y ,  theec  dcvelopnente  can  help  co  elevate  the  crew  ayeten  to 
greater  atatua  In  the  weapon  ayatew  work  breakdown  hierarchy*  Dewonatrated  galna  In  rrew 
syatea  dcvelopnent  ef f ec t 1 venea a  and  efficiency  are  equal  goala*  Baaed  on  clearly  atated 
(projected)  operational  requlreacnta,  the  CAT  proeeaa  will  progreaa  through  atagea  of 
mlsalon  analyala*  functional  analyala/alloca t Ion ,  Integration  and  dealgn,  and 
progreaatve  teat /evaluat Ion.  Thla  auditable  dealgn  proeaaa  will  daternlna  the  need  for 
In  ter rala t Ing  weapon  ayatan  aucoaallon  with  craw  ayatan  operation  baaed  on  ataalon 
denanda,  aircrew  abllltlaa  and  tachnology  coa t/benaf  1 1 *  The  extent  of  autonatlon  will 
be  eatabllahed,  baaed  upon  fornal  engineering  trade  analyaea,  real-tine  piloted 
alnulatlon  teata,  and  objective  aircrew  perforuunce  and  workload  naaaurea*  The  CAT 
proeeaa,  In  particular,  confronta  the  Infornatlon  needa  of  conbat  alrcrewa  to  achieve 
niaalon  aueecaa  with  reallatlc,  aanagcable  aircrew  altuatlon  awareneaa  and  workload*  Aa 
such,  the  crew  aysten  can  beeoae  a  recognised  aircraft  aubayaten  (ef  equal  Inportance  to 
alrfrane  or  propulalon  In  the  weapon  syaten  developnent) * 

The  CAT  project  dellvera  aeveral  related  productat  a  ayatanatlc  and  detallad  crew 
aysten  dealgn  proeeaa,  a  cockpit  autonatlon  dealgn  gulda,  propoaad  revlalona  to  axlatlng 
design  guides  and  standards,  a  cockpit  dealgn  apec 1 f lea t Ion  derived  by  applying  the  CAT 
process  to  a  specific  fighter  nlsslon,  a  breadboard  conputer-alded  das Ign/englneerlng 
syaten  ua  an  initial  Inplenan t a t Ion  of  the  CAT  proeeaa  and  Ita  aoftware  support  tools, 
prototype  1 na t runenfa t Ion  for  effective  neasurenent  of  pilot  perfornance  and  workload  In 
ground  and  airborne  envlronnenta ,  and  verification  of  the  design  process  using 
scientifically  controlled,  engineering  flight,  full  nlsslon  slnulatlons*  Thla  paper 
concentrates  on  the  conputer-alded  support  syaten,  which  we  tern  the  Cockpit  Autonatlon 
Dealgn  Support  Syaten,  or  CADSS  (see  Figure  A).  The  CADSS  Integrates  new  daalgn  tools 
and  techniques  Into  a  self-contained  support  syaten  for  the  crew  aysten  daalgn  tean* 

Progranna t  Ically ,  the  CAT  project  la  organized  In  a  nunbar  of  technical  phasas* 
Phase  1  was  a  definition  phase  and  provided  an  exploration  of  cockpit  daalgn  process 
Inprovenenta .  Phase  2  la  currently  underway  and  Involves  the  full  developnent  of  the 
CAT  design  process  and  the  partial  developnent  of  the  CADSS*  Phase  2  has  two  Industry 
tenna  In  direct  conpatltlon  (one  or  both  nay  be  continued  through  Phase  3,  the 
denonatrat Ion  phase,  which  la  expected  to  connence  In  May  1988),  For  this  reason, 
specific  details  of  the  respeetlve  design  approachaa  for  the  CADSS  are  not  praaented 
herein;  the  discussion  below  la  applicable  co  both  Phase  2  technical  approachaa*  Lastly, 
a  fourth  cecpnlcal  phase  la  planned  and  will  further  denonatrace  and  dlsaenlnace  the 
resulting  crew  aysten  developnent  process,  and  Its  inplenenca t Ion  In  hardware  and 
software,  to  Industry  and  Covernnent  organizations*  Ue  call  this  phase  a  technology 
transition  phase* 

CADSS  CONCEPT  FORMATION 

The  Idea  of  using  conpucer  Infornatlon  tools  Co  support  cockpit  analyala,  dealgn 
and  evaluation  la  not  new*  Despite  aone  noteworthy  Cools,  In  genaral,  craw  ayatan 
dcvelopaent  renalna  predonlnanc ly  a  nanusl  process*  Thla  la  partly  because  cockpit 
developnent  has  been  by  crlal-and-crror  engineering  which  (In  the  past)  did  not  require 
such  support*  Another  likely  reason  la  that  the  cockpit  design  necessarily  Involves 
human  factors,  which  are  difficult  Co  characterize  with  conpuCsr  analysis*  For  exsnple, 
reacarchcra  atlll  disagree  on  fundanental  theories  of  hunan  behavior  for  routine 
situations  (not  to  nenclon  perfornance  under  conbat  stress)*  This  la  particularly  the 
case  for  the  aircrew's  nental  processes  as  they  relate  to  task  perfornance, 
declalon-naklng  and  workload.  In  early  days  of  aircraft  devalopnsnt,  nlsslon 
requlrenenca  and  weapon  syacsns  were  less  conplox  and  Che  slrcraw  could  adapt  so  aa  co 
nake  up  for  cockpit  design  shor tconi ngs *  Today,  howavar,  tha  aircrew  can  no  longer  ba 
regarded  as  a  “slack  variable'  and,  thus,  over-reliance  on  a  purely  experlnental 
engineering  approach  Co  crew  syaten  developnent  la  Insufficient* 

Researchers  In  the  past  two  decades  have  anticipated  that  today's  craw  syaten 
design  process  must  be  supported  by  modern  conputer  tools.  According  to  Lind  (t986)i 
“Previous  attempts  Co  do  this  have  yielded  products  of  low  genaral  utility  and  have 
failed.  In  general,  Co  take  Into  account  the  overall  vagueness,  subjective  quality,  and 
limited  Integrablllty  of  nuch  of  Che  subject  material*  Moreover,  the  Individual  programs 
support  very  limited  portions  of  Che  design  proeeaa  and  make  Itntced  provision  for  the 
manner  In  which  the  crew  ayacens  designer  actually  does  his  or  her  work  and  for  the 
scope  of  the  work  to  be  done*  The  crew  systems  designer,  and  In  f.'ct  any  designer, 
usually  does  not  work  In  a  linear  fashion,  designing  one  step  completely  before  moving 
on  Co  the  next;  rather,  the  designer  will  lay  out  a  rough  design  which  la  then  refined 
through  nany  iceraclona*  No  Integrated  conputer  envlronnent  to  support  this  style  of 
work  exists*' 

Lack  of  success  of  nany  early  attempts  nay  have  contributed  to  o  piecemeal 
developnent  of  computerized  design  tools*  Such  efforts  eonesrnad  Isolated,  stand-alone, 
parts  of  the  problcn*  Dlfflculttss  hove  been  noted  with  excessive  reliance  on  user 
expertise,  with  awkward  and  labor  Intensive  set-up  of  '.nput  date,  with  complex  and 
voluminous  dsts  output  which  requires  lengthy  interpretation  (In  large  system 
dovolopments  design  questions  must  be  resolved  quickly),  with  incompatible  operating 
systems  and  programnlng  languages  (which  prevent  Independently  developed  tools  from 
working  together),  and  with  other  d 1 f f icult las* 
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The  current  generation  of  coaputcr  hardware  and  aoftwara  technology  haa 
algnlflcant  advantagea  over  the  ayatcaa  with  which  previous  design  tools  were 
configured.  Acroes-the-board  advances  arc  underway  In  speed,  aeaory,  software  and  even 
a r t 1 f Ic lal- lot ell Igence  hardware  architectures.  These  can  now  be  eaployad  In  the  attcapt 
to  provide  a  practical  coaputcr  support  envlronaent  for  crew  systea  design  In  service  of 
the  CAT  process.  Part  of  this  recent  progress  la  associated  with  Che  rapid  developaent 
and  Introduction  of  engineering  workstations,  data  base  aanageaent  systeaa,  and 
couputer-aldcd  deslgn/cnglnccrlng  (CAD/CAE)  software.  The  result  la  a  greatly  Increased 
graphics  and  file  aanlpulatlon  capability,  which  appears  necessary  to  lapleaent  a 
practical  CADSS. 

The  CADSS  uuat  support  the  practical  needs  of  the  crew  systea  designer.  It  Is 
unrealistic  to  expect  that  purely  analytic  tools  would  suffice.  Just  as  It  Is 
unrealistic  to  expect  a  great  advance  In  design  technology  would  accrue  fron  totally 
relying  on  the  experlaental  engineering  legacy  fron  the  past.  We  envision  that  Che  CAT 
design  process  oust  aaploy  both  analysis  tools  and  axparlaontal  cools  and,  for  chat 
reason,  have  provided  both  capabillttas  In  our  CADSS  conespt. 

The  CADSS  concept  la  Illustrated  In  Figure  5.  In  a  very  ‘top  level'  deecrlpclon, 
this  systea  Is  coaprlsed  of  four  coaponents. 

(1)  DCADS.  The  aoac  critical  eleaent  of  the  CADSS  Is  what  we  tera  a  Designers 
CoapuCer-Alded  Design  Systea  which  hosts  the  aaln  data  handling  portion  of  the  CADSS.  It 
contains  Che  major  coaputlng  hardware  and  operating  software  of  the  CADSS.  Though 
depleted  as  a  alngla  block  In  Che  figure.  It  nay  be  separated  Into  an  array  of 
supporting  elenents.  The  purpose  of  the  DCADS  Is  to  allow  tha  cockpit  designer  to  use 
computerised  data  bases,  coaputer  aodels,  coaputer  analysis  tools,  simulations,  and 
computer  drafting  Cools.  The  system  will  have  a  general  purpose  central  processing  unit 
as  Its  core  and,  as  shown  In  the  diagram,  tha  DCADS  will  provlda  a  alnulaClon  executive 
for  real-time,  piloted,  part-task  tests  with  a  breadboard  simulator  discussed  below. 
Also  Included  in  the  DCADS  are  several  engineering  workstations.  These  workstations 
represent  a  major  Inpuc/outpuC  envlronaent  for  Che  designer.  Many  of  the  CAE  and 
analysla  cools  needed  for  crew  system  developaent  will  be  hotted  at  Che  workstations, 
but  each  workstation  will  readily  coaaunlcate  with  the  DCADS  central  processor. 

(2)  CAT  Software  Tools.  These  tools  are  being  configured  specifically  to  support 
tlie  designer  In  using  the  formal  crow  system  design  process  being  fully  developed  lii  the 
CAT  project.  The  CAT  software  tools  are  In  two  categories;  coamerclally  available  and 
custom  devclopud/adapted .  Because  they  arc  nature  and  have  been  developed  outside  the 
CAT  project,  some  coaaercially  available  software  tools  will  be  incorporated  into  the 
CADSS.  For  example,  we  envision  that  the  crew  system  designer  will  need  ready  access  to 
data  bases  of  various  natures.  Accordingly,  a  commercially  available  data  base 
mnnugement  system  will  be  needed.  Likewise,  a  variety  of  computer-aided-design  software 
packages  are  available.  Coaaerclal  software  nay  be  Incorporated  to  the  extent  that  It  Is 
needed  for  CAT,  mature,  docunented,  and  likely  to  be  supported  and  maintained.  Other 
software  will  be  custom  developed  or  adapted  for  use  in  the  CADSS.  Specifically  falling 
In  this  category  are  three  analysis  tools  end  a  lessons  learned  data  base  which  arc 
being  devised  In  Phase  2  of  the  CAT  project.  The  analysis  tools  will  support  the  crew 
system  designer  In  mission  decomposition,  function  ana  1 ys 1 s /u 1 Iocs t ion ,  and  Information 
analysis.  Associated  with  these  analysis  tools  will  be  one  or  more  on-line  computer  data 
bases,  also  to  be  developed  In  the  CAT  project.  Such  state-of-the-art  tools  are  not 
commercially  available.  Additional  tools  In  this  category  are  also  shown  In  Figure  6. 

(1)  Breadboard  Cockpit  Simulator.  The  crew  system  designer  needs  convenient 
access  to  a  real-time  simulation  device  with  which  to  quickly  test  new  design  Ideas. 
Mock-ups  used  for  general  layout  and  Inatallatlon  (to  check  clearances,  for  example)  are 
not  adequate  to  use  for  design  decisions  concerning  asny  critical  Issues  Including 
display  conCent/foraat ,  control  procedures  and  pilot  workload.  Due  to  a  relatively  high 
cost  as  well  as  a  demsnd  from  other  design  dlsctpllnss,  high  fidelity  dome  slaulators 
are  often  not  directly  accessible  to  the  crow  systea  designer.  When  s  design  question 
arises  It  usually  needs  iaaedlate  resolution  and  often  does  not  require  the  full  mission 
dome  capability.  In  the  CADSS,  we  make  provision  for  a  very  flexible,  real-time,  part 
task  simulator  that  Is  easily  modified  (both  hardware  end  software)  to  quickly  test  crew 
system  design  concepts.  Importantly,  this  device  Is  under  the  direct  control  of  the  crew 
system  design  team  and  Is  customised  for  the  CAT  process. 

(4)  Software  Executor  Systea.  Some  users  of  the  CAT  design  process,  such  as 
Covurnmont  managers,  asy  require  only  a  design/analysis  support  capability.  This  system 
will  allow  those  users  to  execute  the  CAT  software  tools  without  requiring  direct  access 
to  the  DCADS  or  to  the  breodbosrd  cockpit  siaulstor.  Because  of  the  relief  from  driving 
a  real-time,  man-ln-tke-loop  simulation.  It  will  be  possible  to  configure  this  system  on 
a  smaller  and  less  expensive  coaputer  than  used  for  the  DCADS,  The  systea  Is  envisioned 
to  operate  In  a  typlca.'  office  envlronnnent  and  will  be  easily  transportable.  In 
particular,  this  systea  will  Include  all  CAT  software  too<ls  pertinent  to  the  evaluation 
of  cockpit  dealgn  concepts. 

CADSn  DEVr.LOPHENT  AND  DEHONSTRATION 

Using  the  above  foraulatlon  of  the  CADSS,  two  Independent  Industry  teams  are 
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preparing  designs  which  will  be  developed  In  hardware  and  software*  Figure  7  shows 
which  parts  of  this  effort  ere  underway  In  the  development  phase  (CAT  Phase  2)  and  which 
will  be  undertaken  in  the  demonstration  phase  (CAT  Phase  3)  snd  in  the  transition  phase. 
Detailed  requirements  for  the  CAOSS  are  being  independently  derived  froai  the  CAT  design 
process  being  developed  by  caclr  team.  Where  possible,  this  section  will  describe  common 
requirements  and  design  considerations. 

The  relationship  of  the  CADSS  to  the  CAT  crew  system  design  process  is  shown  in 
Fig  8.  Here,  four  specific  stages  to  the  CAT  process  are  Illustrated.  Both  the  CAT 
process  methodology  snd  the  sppllcation  of  the  CAT  process  are  shown  In  schematic.  Note 
chat  the  CADSS  Is  employed  In  each  stage  of  crew  system  development,  from  the  initial 
conception  and  requirements  definition  through  analys 1 s/des 1 gn/ in t egra t ion  and  Including 
test  and  evaluation.  Two  important  points,  not  Illustrated,  should  also  be  noted. 

First,  crew  system  development  is  a  highly  iterative  process  which  docs  not  lend 
itself  CO  this  kind  of  dlsgram.  In  order  to  have  a  common  basis  for  evaluating  the  two 
CAT  processes  under  development,  we  have  imposed  that  the  CAT  process  be  described  in 
IDRF  notation  (see  Figure  9).  TDEF  stands  for  ICAM  (Integrated  Computer  Aided 
Manufacturing)  Definition  and  is  a  means  of  orgsnlxlng  process  information  according  to 
well-defined  rules.  Figure  10  shows  the  arrangement  of  IDEF  notation  in  terms  of 
activity,  inputs,  outputs,  constraints  (controls)  and  resources  (mechanisms).  For  the 
CAT  application,  the  terms  'constraints*  and  'resources'  better  Illustrate  Che  intended 
meaning,  while  the  terms  'control'  and  'mechunlsm'  were  part  of  the  original  IDEF 
formulation.  The  advantage  of  this  notation  is  that  it  permits  a  progressive 
hierarchical  decomposition  of  process  activity  into  its  lowest  constituent  elements  (sec 
Figure  11).  Each  granular  block  of  process  activity  can  then  be  examined  in  terms  of 
potential  CADSS  usage..  To  illustrate  this  point.  Figure  12  shows  an  IDEF  representation 
for  the  entire  weapon  system.  The  crew  station  portion  highlighted  therein  can  be 
inspected  in  its  own  IDEF  format,  aa  in  Figure  13,  which  details  the  cop  level  inputs, 
outputs,  constraints  and  raaources.  As  envisioned  during  CAT  Phase  1  (Quinn,  1986),  this 
top  level  activity  is  Chen  exploded  into  constituent  activities  in  the  manner  shown  in 
Figure  14.  Each  conscicuent  activity  itself  might  be  further  decomposed  in  the  same 
manner.  Importantly,  all  of  Che  inputs,  outputs,  constraints  and  resources  of  the 
'parent'  diagram  would  be  reflected  in  the  .ipproprlate  'child'  diagram. 

Again  referring  to  Figure  8,  the  second  important  point  to  be  made  ia  that  this 
diagram  depicts  crew  system  design  relationships  in  Che  CAT  process.  Yet,  in  application 
CO  Che  overall  weapon  system  development,  these  relationships  will  be  effected  by  the 
evolving  maturity  of  Che  weapon  system  itself.  That  is,  Che  design  emphssls,  activity 
and  labor  level  of  effort  (and  hence,  CADSS  usage)  will  change  depending  on  Che  phase  of 
Che  weapon  system  acquisition  process.  In  the  United  States  these  weapon  system  process 
phases  are  known  as  Concept  Exploration,  Demonstration  and  Validation,  Full  Scale 
Engineering  Development,  and  Production  and  Deployment.  Crew  system  design  activity 
changes  with  passage  from  weapon  system  phase  to  weapon  system  phase.  The  CAT  process  is 
being  developed  in  tight  coupling  with  the  weapon  system  process  (see  Figure  15). 
Therefore,  CADSS  design  requirements  must  consider  not  only  the  hierarchical  granularity 
of  necessary  crew  system  activity  noted  above,  but  also  which  weapon  system  development 
phase  is  currently  active.  These  two  important  dimensions  Co  setting  Che  CADSS 
development  specifications  are  significant.  The  CADSS,  and  the  CAT  process  it  supports, 
will  be  Judged  by  Its  demonstrated  improvements  In  design  efficiency  and  design 
effect  Ivaness . 

Demonstrating  the  value  of  the  CADSS  in  terms  of  design  efficiency  and  design 
effectiveness  are  separate  problems.  True  validation  in  these  areas  is  Infeasible 
because:  (1)  there  is  no  accepted,  well-understood  standard  of  comparison  for  the 
'current'  crew  system  process  and  its  supporting  methods  and  Cools,  and  (2)  the  scope  of 
the  CAT  project  is  confined  to  ground-based  simulation  for  proof-of-concepc .  Subjective 
estimates  of  design  efficiency  will  be  possible  by  applying  the  CAT  process  (Itself 
generslixable  beyond  a  specific  pre-dsflned  opersclonsl  mission)  to  a  specific 
Covernmeot  furnished  mission  scenario  (requirement).  Using  the  CAT  process,  supported 
by  the  envisioned  CADSS  support  environment,  a  specific  cockpit  crew  system  is  being 
designed  in  Phase  2  and  will  be  fabricated  and  tested  in  full-mission  simulation  in 
Phase  3.  It  will  be  possible,  through  objective  measures  of  task  effectivenes  In  the 
Phase  3  real-time  simulation,  to  infer  design  effectiveness.  This  will  be  approached  by 
direct  comparison  of  the  CAT  crew  system  against  s  baseline  crew  system  derived' by 
'conventional'  crew  aystem  dasign  practice  (using  common  missions,  weapons,  threats  and 
pilots  for  this  comparison).  These  demonstration  events  have  yet  to  be  planned  in 
detail.  However,  there  is  provision  during  Phase  3  for  600  hours  of  real-time,  piloted, 
full  mission  combat  simulation  (exclusive  of  testing  with  the  breadboard  cockpit 
simulator  described  above). 

The  technical  approach  being  followed  in  both  ongoing  CADSS  developments  is  toward 
an  integrated  aystem  that  will  support  all  craw  system  snalySiis,  design  and  evaluation 
activities  throughout  all  weapon  system  development  p'assss.  Although  well  over  100 
existing  computer  software  programs  have  been  evaluated  for  potential  use  in  the  CADSS, 
only  a  relatively  small  number  of  key  tnnia  will  arfactlvoly  aid  in  crew  system 
davslopment.  Considerabla  dlffersnees  exist  In  the  Phase  2  approaches  for  CADSS 
architecture  (both  hardware  and  software)  and  envisioned  CADSS  application.  At  this 
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time,  a  conparlson  of  approaches  la  prenature.  In  general,  the  CADSS  la  being  designed 


(1)  Support  the  CAT  analyats  software  algorithms, 

(2)  Support  the  CAT  data  bases  and  data  bass  rnsnagamant  system, 

(3)  Support  the  CAD  packages  adopted  for  the  CAT  process, 

(4)  Support  the  Incorporation  of  new  design  evaluation  tools  as  may  be 
developed  outalda  the  CAT  projeef, 

(3)  Support  the  CAT  crew  system  evaluation  cools, 

(6)  Support  the  real-time  breadboard  cockpit  simulation, 

(7)  Support  downloading  the  appropriate  DCADS  software  to  the  Software  Exeeutsr 
System  envisioned  for  use  in  an  office  environment, 

(B)  Supprrt  Industry  standard  Interfaces  to  permit  the  broadest  dissemination  of 
CAT  products, 

(9)  Permit  an  upwardly  compatible  path  for  system  growth, 

(10)  Support  the  configuration  management  and  design  decision  tracsabillcy  of  crow 
system  development. 

TECHNOLOGY  TRANSITION  CONCEPTS 

Particular  «  c-nclon  has  been  directed  coward  the  eventual  uses  of  the  CAT  crew 
system  design  proc...s  and  Its  supporting  CADSS.  In  the  final  analysis,  system  process 
and  process  support  tools  will  be  seceptud  ai.d  used  only  when  Che  practical  advantages 
are  understood  and  demonstrated.  Transition  of  this  kind  of  technology  requires  more 
then  e  letter  of  transmittal  end  receipt  of  equipment.  The  CAT  project  le  being 
developed  end  maneged  by  an  interd lee tpl Inary ,  Int e r-orgsnl ts t lonsl  USAF  team  with 
representation  of  the  Human  Syacems  Division,  the  Harry  C.  Armstrong  Aerospace  Medical 
Research  Laboratory,  the  Avionics  and  Plight  Dynamics  Laboratories  of  the  Air  Force 
Urlght  Aeronsutlcel  Laborstoriee ,  end  the  Aeronautical  Systems  Division,  Deputy  for 
Engineering  (A8D/BN). 

Responding  to  the  above  concern,  the  CAT  project  office  has  ostsbllshed  a  formal 
Technology  Transition  Plan  which  represents  an  agreement  naming  ASD/EN  es  recipient  of 
the  technology.  This  organisation,  in  turn,  will  adapt  the  technology  for  exploitation 
In  major  system  development.  Specifically  Identified  In  this  transition  plan  Is  a 
separate,  funded  transition  effort  (noted  above)  which  will  assist  ASD/EN  In  testing, 
acquiring,  ualng  and  supporting  the  deliverables.  It  Is  expected  that  the  CADSS 
described  In  this  paper  will  be  upgraded  by  s  second  generation  variant  In  that 
transition  development. 

Also  related  to  the  Transition  Plan,  the  CAT  project  office  has  consolidated  an 
understanding  with  the  Advanced  Tactical  Fighter  (ATF)  System  Program  Office.  This 
agreement  provides  for  making  CAT  project  developments  available  for  use  In  that 
prugr-f".  Accordingly,  the  CAT  project  schedule  Is  coordinated  with,  and  technical 
progress  Is  monitored  by,  the  crew  system  engineering  function  In  the  ATF  development. 
This  close  coordination  assures  ASD  participation  In  CAT  project  planning,  decisions  and 
milestones.  More  Importantly,  this  presents  an  opportunity  to  test  the  viability  of  the 
developing  crew  system  design  process  and  tho  CADSS  In  s  realistic  development  setting 
and  to  make  necessary  adjustments.  The  active  Involvement  of  tho  engineering 
development  'customer'  In  an  advanced  technology  development  enturprlee  Is  considered 
noteworthy  with  respect  to  planning  for  the  technology  transition. 

CONCLUSIONS 

Current  design  methodologies  available  for  crew  eystem  dsstgnere  are  embodied  In 
design  handbooks  (AFSC  DH  1-3  and  2-2),  military  standards  (HIL-STD-1472C  and 
HIL-STD-1776  )  and  military  spec  1 f lest  lone  (MIL-H-A6S33  )  .  These  methodologies  are  too 
general,  antiquated  In  terms  of  the  technology  assumed,  end  do  not  snewsr  the  paramount 
qusstioni  'what  does  the  crew  needT'  Thsas  methodologies  focus  on  general  cockpit 
layout,  control/dlepley  arrangements,  and  anthropometric  studies  that  support  cockpit 
Inetsllstlon  and  physical  fit.  They  also  provide  for  pert-task  elmuletion  which  helps 
define  cockpit  procedures  end  function.  Up  until  the  atd-l970s,  this  proesdure  was 
adequate  due  to  limited  alternatives  In  cockpit  componentry  automation  end  avionics,  a 
more  limited  flight  envelope  end  e  (eompsrac tvely)  benign  threat.  The  situation  since 
then  has  changed  In  that  we  new  have  the  capability  to  completely  overwhelm  the  aircrew 
with  complex  control  swltehology.  unlnterpretabls  displayed  data,  and  automation  modes 
which  may  or  may  not  help.  Crew  system  design  nathede  have  net  kept  pace  with 
alr-vehlele,  avionics  end  weapons  advances. 

The  UBAF  Cockpit  Automation  Technology  Project  attempts  to  correct  this  situation 
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by  slH te-of ~ the^art  advanccsent  In  craw  systaw  design  technology*  The  focua  of  thla  work 
la  with  a  coaputer-aupported,  aathodologlcal  daalgn  procaaa  that  aacka  to  lapoaa 
discipline  on  today's  practice  (with  all  Its  current  lialtatlons)  •  A  critical  part  of 
the  CAT  project  la  the  Cockpit  Autoaatlon  Design  Support  Subsystea,  without  which  It 
would  be  unrealistic  to  expect  significant  gains  In  either  crew  systea  design  efficiency 
or  design  effectiveness*  Soaa  of  the  envisioned  users  of  tha  CADSS  are  depicted  In 
Figure  16*  Because  of  the  Interaction  of  the  crew  aystea  with  other  components  of  the 
air  vehicle  (Figure  17),  the  CADSS  aay  eventually  be  used  In  conjunction  with  other 
coaputer  based  support  systeas  that  will  likely  evolve. 

The  CAT  project  la  advanced  technology  developaent*  For  the  first  tine,  a  critical 
aass  of  funding,  along  with  In ter-organ lea t tonal  cooperation  within  both  Covernaent  and 
Industry,  la  being  brought  to  bear  on  a  atate-of-the-art  ndvance  In  the  cockpit  design 
practice*  Even  partial  success  of  this  aabltlous  project  will  contribute  to  future 
gains,  both  In  developacntal  efficiency  and  In  operational  suitability*  Greater  success 
can  lead  to  reductions  In  developnent  tine  and  acquisition  costs  (In  nlnlnlelng  the  need 
for  engineering  changes  with  their  attendant  Inefficiencies)*  Together  with  the  advanced 
life  support  and  escape  syaten  projects,  the  Cockpit  Autoaatlon  Technology  Project 
offers  a  nan-centered  orientation  for  future  systen  development* 
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FIGURE  1.  CREW  SYSTEMS  INTEGRATION. 
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FIGURE  2.  CAT  PROJECT  OBJECTIVE 


•  NOT  standardized  •  SIMULATION  UNDEREXPLOITED 


•  TOTALLY  PEOPLE  DEPENDENT  •  SIMULATORS  INACCESSIBLE 


•  SCHEDULE  DRIVEN  •  SCENARIO  DETAIL  LACKING 


•  MANUAL  PROCEDURES 

•  APPLIED  LATE 

•  design  GUIDES  OUTDATED 


•  WEAPON  SYSTEM  PROCESS 
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FIGURE  3.  LIMITATIONS  OF  CURREN"^  PROCESS 
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•  ONLINE  DATABASES 

•  DBMS 

•  audit  trail 


CENTRAL  PROCESSOR 


PROCEDURES 


FIGURE  4.  CADSS  —  CONFRONTING  THE  LIMITATIONS. 
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figure  5.  COCKPIT  AUTOMATION  DESIGN  SUPPORT  SYSTEM  ICADSS) 

•  MISSION  DECOMPOSITION  TOOL 

•  FUNCTION  ANALYSIS/ALLOCATION  TOOL 
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•  DATA  BASE  MANAGEMENT  TOOL 

•  COMPUTER  AIDED  DESIGN  TOOL 

•  SIMULATION  SOFTWARE  TOOL 
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FIGURE  6  CAT  SOFTWARE  TOOLS 
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FIGURE  7.  CADSS  EVOLUTION. 
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FIGURE  8  RELATION  OF  CADSS  TO  CAT  METHODOLOGY. 
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•  DISCIPLINED  GRAPHIC  CHARTING  TECHNIQUE 
EMPLOYING  RIGID  RULES  AND  CONVENTIONS  FOR 
ORGANIZATION  AND  REPRESENTATION  OF  PROCESSES 

•  CHARACTERIZE  HIERARCHICAL  AND  CONNECTIVE 
RELATIONSHIPS  AMONG  PROCESS  ELEMENTS,  INPUTS 
OUTPUTS,  RESOURCES  AND  CONSTRAINTS 


PROVIDES  BACKUP  GLOSSARIES  AND  NARRATIVE 
DESCRIPTIONS  OF  GRAPHICS 


FIGURE  9.  IOEFq  FEATURES. 
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FIGURE  10.  TYPICAL  IDEFq  FORMAT. 


FIGURE  11.  lOEFg  PARENT-CHILD  RELATIONSHIP. 
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FIGURE  12.  ID6F  FOR  WEAPON  SYSTEM  DEVELOPMENT. 
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FIGURE  13.  IDEF  FOR  CAT  DESIGN  PROCESS. 
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RESUME 

Catta  conBoronco  prosento  lorgsrusation  at  Jas  moyens  mis  on  pjaca  pour  Ja  Pavaioppamant  du  systama 
avionigua  das  DAUPHIN  365  f  S.A.R  da  1' aER0SPA7IAL£ .  at  an  particuliar  du  sous-systama  da  nav’igation 
at  .'a  gastion  da  mission  davaloppa  par  CR0UZE7.  Apras  una  description  das  missions  do  I'svion  at  da 
i 'arcn«  tactura  du  systama.  I  'accent  ast  mis  sur  I  organisation  das  travaux,  antra  ai/ionnaur  at 
sous-systamjnr.  puis  sur  las  difforonts  moyans  mis  an  oauvra  c^ar  i  •duipamantiar  comma  cnoz 
1' avionnour  pour  assurer  ia  succas  d'un  tal  developpement . 


INTRODUCTION 

La  concaptjon  at  le  developpement  da  systamas  avioniguas  complexes  font  appai  a  da  nombreuses 
techniques  et  mettent  an  oeuvre  plusieurs  mtervenents  et  differents  moyens. 

Ainsi  i  '  evionneur .  qui  assure  lui-meme  an  tant  aua  maitra  d  oeuvre  du  systama  la  concaptio,*<  giodaia 
das  specifications  du  systama.  puis  ia  rasponsaOiiita  das  pnasas  d '  integration  au  sol  et  d'es»ais  an 
voi.  sa  trouva  confronts  a  ia  gastion  d'un  progat  compiaxa.  dont  ias  intervenants  principaux  sont 
constituas  par  les  equipementiers  mayeurs  qui  fournissent  ias  aiamants  assantiais  du  systama. 

une  metnodologie  rigoureuse  esC  necessaire  pour  manar  a  Pian  ca  pro^at,  aiia  inclut  nctanment  le 
res.-^ect  d  una  granda  riguaur  au  rtveau  das  specifications,  una  atroita  cooperation  antra  i’avionnaur 
at  'as  fournissaurs .  ainsi  Qua  1  ' utilisation  da  moyans  codarants  at  complementaires ■ 

Un  axampia  significatif  ast  constitua  par  ia  systama  avionique  specif iquement  davaloppa  par 
i ' iarospatiaia  an  collaboration  avec  differents  equipementiers  ICROU2B7  -  SPIN  -  6£NDIX)  pour 
1  equipement  das  helicopteres  de  recherche  at  da  sauvataga  an  mar.  Ca  systama  a  ata  notammant  mis 
an  oauvra  sur  ias  OAOPHIN  365  F  iivras  a  1  /risd  Air  Corps. 

las  raiations  avionnaur-aquipamantiar  sont  dacritas  a  travars  ia  cooperation  antra  1 ' Aerospatiale  at 
ia  sociata  fournisseur  du  systeme  de  navigation. 

I.  PRESENTATION  GENBtALE  DU  SYSTEME 

J.  J  DESCRlP7107t  D£  LA  MISSION 

La  mission  prmcipale  de  I'helicoptere  est  la  recherche  at  le  sauvataga  an  mar. 

Catta  mission  paut  atra  decrite  a  partir  d'un  schema  representant  le  profil  de  vol  : 
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B1 


B2 


Ce  profit  se  decompose  en  huit  (8)  phases  ; 


-  phase  A 

-  phase 

-  phase  C 

-  phase  0 

-  phase  E 

-  phase  F 

-  phase  82 

-  phase  G 


:  d4col(age-^moncie  i  I'altitude  de  croisi^re 
:  rejointe  de  la  zone  de  recherche 
;  trajectoires  de  recherche  (Pattern  de  recherche) 

:  descente  vers  le  stationnaire  (Transition  down) 

;  stationnaire  (HOVER).  Operations  de  treuillage 
:  montee  vers  I'altitude  de  retour  (Transition  UP) 
:  croisiere  retour 

:  descente  approche  -  atterrissage 


Les  phases  A  •  -  B2  •  G  sont  des  phases  classiques  du  vol.  Les  phases  C  •  D  -  E  F  correspondent  aux  phases  de  !a  mission  SAR 

proprement  dite. 


phase  C  —  L'h^Hcoptere  est  arrive  sur  la  zone  de  recherche.  Dans  cette  phase  i!  devra  couvrir  cette  zone  jusqu'd  localisation  de  son 
objectif. 


phase  O  —  Cette  phase  consiste  d  effectuer  une  transition  vers  le  bas  pour  venir  se  placer  en  stationnaire  au  dessus  de  I'objectif. 


phase  E  —  Mr'ntien  du  stationnaire  jusqu'd  la  fin  de  ('operation  de  treuillage. 
phase  F  -  Transition  vers  le  haut  pour  rejoindre  I'altitude  de  croisiere  retour. 


t.3  ASCHlTECTUftS  DU  SYSTEMS 

hour  assumer  cette  mission,  I ' heiicoptere  cftoisi  eat  un  d»upftin  naval  de  la  classe  iOOO  kg  eovipe 
dun  systeme  de  mission  inciuant  des  visualisations  de  plancne  de  bord  a  ecrans  catnodiques. 


LM 


L9  syst9m9  mission  9st  scind9  on  trois  sous^systomes 

-  un  sous-syst9m9  mvigotion  ot  de  gostion  de  mission 

-  un  sous~syst9me  pilotago  automatiquo 

-  un  sous-syst9m9  radar  et  visualisation 

Ce  systoma  «st  parfaitomont  intigro  at  utiliso  das  liaisons  numariques  pour  las  dialogues 
principaux.  Son  architactura  ast  schamatisaa  par  la  diagramma  suivant  : 


BAD  I  ; 

EHSI  : 

S.6  : 

B. A.T.I.B  : 
I.U  : 

D.C.P  : 
F.O.C  : 

C. O.U 


Electronic  Attitude  Display  Indicator 
Electronic  Horizontal  Situation  Indicator 
Symbol  Generator 

Boitier  d' Adaptation  at  de  Traitement  d' Informations  Electriques 

Interface  Unit 

Display  Control  Panel 

Plight  Director  Coupler 

Control  and  Display  Unit 


O.N.S  : 


OMEGA  Navigation  System 


Cette  arcfixtecture  est  organisee  eutour  <je  3  celculeteurs  : 

*  Le  ciLcoleteur  coupieur  dirscteur  d«  vol  qui  assure  les  fonctions  classiques  de  pilotage 
automatiQue  du  vol  et  la  mise  en  stationnaire  automatique 

-  Le  calculateur  recepleur  de  navigation  0H£6A 

-  Le  calculateur  NAOIfl  MK2 

La  suite  de  I'expose  decrit  plus  partxculierement  le  sous - systeme  de  navigation  et  de  gestion  de  la 
mission 


1 . 3  LE  SOUS-SYST£M£  DE  NAVI6AT10H  ET  Df  GESTION  Pf  HliSIOk 

Le  sous  -systeme  de  navigation  et  de  gestion  de  mission  est  articule  autour  de  deux  calculateurs .  ‘Jn 
calculateuA  principal  qui  assure  la  totalite  de  la  gestion  navigation  et  un  recepteur  OHCGA  qui  en 
fonctionnement  normal  a  un  role  de  senseur  de  position . 

£n  cas  de  def alliance  du  calculateur  principal .  le  recepteur  OMEGA  retrouve  sa  fonction  calculateur 
de  navigation  plus  recepteur  OMEGA  et  assure  automat iquement  poursuite  de  la  navigation  en  cours. 

Le  senseur  OMEGA  est  un  EOulNOX  OMS  tOO  A  de  la  sociece  C»0u2Ef. 


t.  3.  i  Calculateur  principal  NADIR  MK2 

Le  calculateur  principal  de  navigation  est  le  NADIP  MK2  produit  egalement  par  CttOUZET . 

Ce  calculateur  a  ete  concu  pour  satisfaire  les  exigences  des  systemes  modernes  actuals  et  futurs. 
notamment  en  ce  qui  concerne  la  puissance  de  calcul.  la  taille  memoire.  et  la  capacite 
d  entrees -sorties . 

Ainsi.  dans  1  example  du  DAUPHIN  165  f.  le  calculateur  NADIR  MKZ  est  reJie  , 

•  Aux  differents  senseurs  lui  permettant  d  assurer  une  localisation  mul  ti ■ senseurs  . 

.  Cap  (corneas  gyromagnetique) 

Attitude  /gyroscope  de  verticaie/ 

Radar  Doppler  de  navigation 
.  VOR/DME  (2  .'OR  -  I  ONE) 

.  OMEGA 

-  Soitier  Capteur  de  Pressions  permettant  le  calcul  des  parametres 
anemoparometriques 

•  Aux  dePitmetres  de  car&urant,  ce  aui  permet  d'entretenir  en  permanence  les  para'>etres 
consommat ion .  masses  machine  et  carburant.  distance  franchissable .  et  d  assurer  les  fonctions  ae 
gestion  carburant.  gestion  des  performances. 

-  Au  pilote  automatique.  au  radar,  et  aux  instrumenis  de  pilotage  electroniques .  a  travers  les 
bottlers  d  interfaces  'BAflE'  t  et  2. 

•  Au  radio  altimetre. 

■  A  son  ooste  de  commsnae  et  de  visualisation  (PCV  a  tuJ>e  cathodique) . 

Le  synoptique  du  sous-systeme  est  decrit  ci-apres 


L»s  /onctions  prineip4i2«s  </u  ealculit«ur  pav^i^ation  NAOI/l  MK^  sent  rasumaes  ci-apra$ 


-  NAVIGATION  : 

Troit  positions  prtaantas  sonc  alaboraas  an  parmanance.  a  partir  das  informations  : 

.  Oopplar 
.  OMCGA 
.  V0P/0M€ 

-  GESTION  DU  VOL 

.  MomorisMtion  das  puts  at  das  routas 
.  Castion  du  plan  do  vol  at  das  pattorns  da  racftarcna 
.  Calcul  das  paramatras  da  navigation  sur  la  routa 

-  GESTION  CA8eu8ANT 

.  Consonmation .  massas  carPurant  at  macPina 
.  Vitesse  da  croisiara  aconomipua 
.  Caicuis  da  masse  dacoiiaPia 
.  Calculs  pradictifs  da  distanca  f rancPissaPla 

-  C0UPLA6E  PILOTS  AUTOHATIOUE  ET  INSTRUMENTS 


SURVEILLANCE  ET  RECONFIGURATION  DU  SOUS-SYSTEME 


Six  modes  de  guidege 


sont  possibles  : 


■  FROM/ TO 

-  DIRECT  TO.  avec  ou  sans  radiile  preferentielle 

■  Rslii»m»nt  d  un  but  mobile 

-  Mavigetion  sur  une  route 

-  FATTERNS  de  recrtercbe 

-  Nise  en  stationnaire  IHOVER)  apres  transition  automatiQue 


EVOLUTIONS  GUIDEES  EN  HORUONTAL  ET  VERTICAL  LORS  DE  LA  MlSE  EN  STATICNNAIBE  AUTOMATlQuE 
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t.3.2  ProceasmuT  utilise 

Pour  roalisor  I'onsombio  de  cos  fonctions,  uno  importo/ite  puissance  d»  cslcul  ost  necessaire.  Cost 
pourouoi,  dans  ia  conception  du  NADIB  MK2,  CROUZCT  a  utilise  uno  Unite  Arithmetique  tres  puissante . 
1' ALPHA  732.  entierement  concue  pour  les  Pesoins  avsoniques . 

II  s'agit  d'un  processeur  32  bits,  trauaiilant  en  uirgule  fixe  ou  virguio  flottante,  de  la  classe  de 
1  million  d'operations  par  seconde. 

Co  calculateur  est  programmable  en  PASCAL. 

Un  atelier  logiciel  tres  puissant  a  ete  confu  par  CB0U2CT  pour  permettre  une  production  aisee  de 
logiciels  importants  ainsi  que  pour  assumer  une  grande  capacite  d'evolutions  ot  do  modifications . 
cos  coractoristigues  etant  essentielles  pour  la  roussito  d'un  prograaeiie  d' integration  de  systeme 
complexe  comme  celui  du  DAUPHIH  SAB  365  F. 

Ainsi.  tant  dans  la  conception  materielle  que  logicielle  du  calculateur  ALPHA  732.  ont  ete  prises  en 
compte  les  contraintes  liees  a  1 ' integration  dans  un  systeme  avionique  important  : 

-  fonctionnement  multi-taches . 

-  production  de  logiciel  par  mise  on  paraliolo  do  plusiours  oguipos, 

•  parfaite  adaptation  aux  contraintes  to/nps  rool, 

-  fliiso  on  place  de  moyens  de  mise  au  point  puissants . 

•  documentation  abondante  et  detaillee . 

Pour  la  production  de  1  ' application  DAUPHIN  365  F,  environ  200  Koctets  Ce  logiciel  one  oto  ocrits  en 
PvtSCai.  ou  ASS£MSL£UB. 


2.  QfBQUFMFWT  nUMfUFT 

2.  t  CALENDRlEg 

L»  c/9i/elopp0m«nt  du  syateme  s  eat  vt^ntfu  sur  3  sns  et  dsmi  S02on  la  planning  suivant 
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Si^n&iurt  Ju  Canh^i. 
Jiifmitidfi 

|Preparition  /nlgralioi 
iDfvetoppemnt 

Livraiior)  Bijuipt 
Eiidb  ini^aifbn  4ol 

f-'  i/oL  ^iUmt 
puij  tiSdis  vdL 

Li  vraiion. 
Strit 


ENCHAINCMENT  DES  TACHES  OE  BEYCLOPPEHClir 

La  davaloppamant  d  un  t«i  5yst9««  s«  tratfuxt  par  un  anchainamant  da  tachas  succassivas  qui  mettront 
a  contribution  plusiaurs  aarvicaa  chaz  I'avionnaur  at  chaz  1 ' aquipamantiar  :  buraau  d  etudes. 
production,  assuranca  qualita.  ate  .... 

L ’interaction  das  tacfiet  eexonneur  et  eouipeetentier  sa  traduit  par  la  necessite  : 

-  d'un  dialogue  constant 

-  dune  granda  riguaur  dans  I'achanga  das  informations  de  definition 

-  d'una  structure  de  travail  favorisant  un  temps  de  reaction  minimum. 

On  paut  rasumar  I'anchainamant  da  cas  tachas  par  la  tablaau  qui  suit  : 
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Par  ailleurs.  le  controls  de  la  Qualito  interviont  a  toutes  las  stapes  dss  I'slaboration  dss 
spscxfrcations .  jus<7u'i  la  rscsptxon  fxnals  ds  la  machine. 

infxn.  1  'etude  et  Is  developpsment  ds  moysns  ds  maintenance  peut  s  ' sffectuer .  en  parallele  du 
developpement  du  systems,  sn  fonctxon  dss  dsmandes  du  client. 


2.3  MALTRISE  DES^EVOLUTIONS 

Quelle  Qus  soxt  la  gualxts  avsc  laquells  les  specifications  ont  ete  etablies  et  le  systems  realise, 
des  incidents  et  des  evolutions  sont  a  attendre.  Elies  proviennent  de  differentes  causes  ; 

-  Des  erreurs  de  realisation  relevees  dans  one  configuration  particuliere  ou  dans  un  environnement 
non  teste  en  recette 

-  Des  erreurs  de  specifications  dues,  pour  certaines.  a  I'absence  d'outils  de  specifications 
performants  permettant  da  decrire  le  fonctionnement  reel  du  systeme 

■  Des  evolutions  de  specifications  souhaitees  par  le  client 

La  prise  en  compte  de  ces  evolutions  conduit  a  la  creation  de  versions  successives  qu  il  faut 
ensuite  gerer  correctement 

Aussi  est-il  indipensable  de  maitriser  ces  evolutions  par  un  processus  du  type  de  celui  mis  en  place 
pour  le  calculateur  NADIR  MK2  du  DAUPHIN  SAP 

-  Cheque  ano/naiie  constatee  cner  I  'avionneur  ou  1 'eu oementier  apres  la  recette.  donne  lieu  a 
I'emission  dune  Fiche  d' Incident 

-  Ces  fiches  a'ln-idents  sont  analysees.  Trois  ces  peuvent  se  produire  : 

.  soit  I'anomalii  constatee  s  explique  par  un  contexte  particulier  et  n'lmpliQue  pas  uno  evolution 
de  I'eQuipemen 

.  soit  I'anomalie  provient  d'un  defeat  de  1  equipement  par  rapport  aux  specifications  .  La 
modification  est  appliuuee.  et  fait  1  objet  dune  Fiche  a  Evolution. 

.  soit  1  anomalie  conduit  a  une  evolution  de$  specif icaiioos .  On  cree  une  fiche  d  Evolution  qui 
sera  SMaminee  commun  entre  Avionneur  et  Equipementier. 

Apres  decision  eventuelle  d  application.  I'evolution  est  realisee.  testae  et  integree  a  une  version 
ulterieure  de  I  ' equipement . 

Cette  procedure  permet  une  parfaite  identification  des  diverses  anomalies  et  une  bonne  maitrise  des 
evolutions  demandees.  Elie  permet  egalement  de  bien  identifier,  sur  le  plan  des  coats,  i  impact  de 
ces  evolutions,  et  leur  imputation  reelJe  (equipementier.  avionneur.  ou  client  final! 

3.  MOYEHS  m  Bi  OBJVRE 

Le  deroulement  d'un  projet  de  cette  dimension  necessite  la  mise  en  oeuvre  d'un  certain  nomhre  de 
moyens  specif iques  adaptes  aux  phases  : 

•  de  specifications 
~  de  developpement 

-  d ' integration 

-  d ' exploitation 

A  ces  moyens.  se  rajoute  I'ensemble  des  moyens  generaux  tels  qua  les  moyens  de  qualification 
d'equipement  et  de  simulation  d ' environnement . 

3. 1  MOYEHS  DE  SPECIFICATIONS 

La  phase  de  specifications  revet  une  importance  particuliere  :  sa  bonne  execution  permet  de  reduire 
les  risques  d'evolutions  ulterieures .  done  les  couts  et  les  delais. 

Elle  implique  la  participation  active  de  nombreux  intervenants  ;  I  utxlisateur  final,  ies  bureaux 
d'etudes.  les  equipages  d'essais  en  voj,  etc--- 

C'est  avant  tout  une  phase  de  communication  au  cours  de  laquelle  li  faut  imagmer  ce  que  sera  le 
fonctionnement  reel  du  systeme  futur. 


Pour  CO  foito,  dot  mo^ont  partxculi^r*  doiuont  itro  mii  §n  oouvro.  d«n«  1«  doublo  but  : 

•  do  «u«cit«r  1«  cofl«Runic«tion  tntr*  lot  intOTvontntt 

'  do  couvrir  lo  pJLut  oxfuugtiuooio/tt  potoxblo  lot  confxgurttiont  do  fonctionnomont  Jw  <yit«/R«. 

On  oMomplo  timplo,  molt  offieoco.  o*t  i‘utiIi«ation  dun  micro-ordinttour  do  la  claaaa  I0M  PC-AT 
pour  dicTXTO  lot  popot  d'un  potto  do  comundo  ot  do  uitutlitttxon. 

Un  tutro  oxomplo.  plus  comploxo.  ott  colui  dun  outxl  d  aid#  i  la  concoption  d'uno  archxtocturo 
fonctionnollo  do  tyttomo  t«l  qu*  cdlui  dncrit  dana  !•  tenina  ci-doatout  : 


f 


/inj" . 

/  ”in”7n _ i  ~  / 


Etfuiptm^ni  _ / 


Nivtau  hf: 

Feftciiont 

f/ementa.ins 


20-12 


La  pramiira  phaaa  du  travail  consiat^  i  dieoopos0r  finaatmnt  la  aystama  an  dacrivant  las  fonctions 
par  laurs  Entraas.  Sortias.  Macanismas  at  Controlaa  jusQu'au  nivaau  souhaita. 

Enauita  on  procada  au  ragroupamant  das  tonetiona  alamantairat  pour  affactuar  la  projaction  da 
1 ' arehitactura  fonctionnalla  sur  I'architactura  matarialla  a  partir  da  xagualla  on  paut  acrire  la 
spacification  dataillaa  das  aquipamants  (matarial  at  logicialf  at  an  particuliar  la  spacification 
dataillaa  daa  traitaatants  ralatifs  auM  fonctions  gui  doivant  s  axacutar  dans  chagua  aguipamant. 

3.2  HOYENS  PC  DEYELQPPEMEHT 

Caa  moyans  parmattant  la  davaloppamant  puis  1‘intagration  vt  1<  misa  au  point  da  1  aguipamant . 

Pour  un  aguipamant  t«i  qu«  la  calculataur  da  navigation  at  da  gastion  da  mission,  una  attantion 
particuliara  doit  atra  apportaa  aux  moyans  da  davaloppamant  du  Jogicial. 

L'ataliar  logicial  congu  pour  la  calculataur  ALPHA  732  ast  un  ansambla  d'outils  parmattant  da 
produira  at  mattra  au  point  una  application  dans  un  contaxta  da  davaloppamant  : 

•  multi- fonctions  :  una  application  sa  dacomposa  an  un  lot  da  fonctions  intarconnactaes 

-  multi-utilisataurs  :  una  application  o$t  davalopp**  par  plutiaurs  aguipas  an  parallala 

Cat  ataliar  gui  mot  an  oauvra  das  mathodas  da  concaption  logicialla  propras  a  1  ‘ aaronautigua . 
comporta  daux  tvoas  d'outils  : 

-  una  chaina  da  production  logicialla 

-  un  systama  da  misa  au  point 

3.2.1  Mithodtt  dt  conctDtion  du  lOQiciti 

La  realisation  d'un  logicial  complaxa.  tel  que  celui  d'un  calculataur  da  gestjon  da  mission,  impose 
1  utilisation  da  mathodas  da  conception  parmattant  d'una  part  d'assurar  una  production  rapida.  at 
d'autra  part  da  facilxtar  au  miaux  las  intarvantions  ultariauras  sur  ca  lopiciej.  au  nivaau  d»  la 
phase  da  'maintananca' . 

Cas  mathodas  raposant  sur  daux  principas  da  base  : 

-  una  description  arboraseanta  da  1' application,  qua  a  chaoua  fonction.  associa  un  ansambla  da 
tachas.  at  un  ansambla  da  liens  antra  cas  tachas.  dapuis  1  ‘ application  complete,  jusgu'au  nivaau 
da  modules  qui  constituent  da  varitabias  composants  logieials  : 

AfiPLlCATIOH  ;  Ensemble  da  FONCTIONS  •  Ensemble  da  HENS. 
rCUCTION  :  £nsemple  da  T ACHES  •  Ensemble  da  LIENS. 


APPLICATION  :  Ensemble  da  MODULES  *  fnsemPle  da  LIENS. 

Cette  analyse  prolonga  la  description  arborescente  gui  a  ate  faita  au  niueau  systama. 

-  La  presence  d' informations  documentairas  abondantes.  jusqu'au  niveau  das  modules,  afin  d'assurar 
la  meilleure  lisibilite  possible. 

Das  outils  logicials  specif igues  ont  ete  crees  pour  assurer,  an  application  da  ces  methodes,  la 
conception  du  logicial  : 

.  genarateur  d  applications  (descriptif  das  liens  interfonctions ) , 

.  otftil  de  saisie  documentaire, 

.  outils  de  simulation, 

.  etc. . . 

3.2.2  cntint  dt  aroductjon  loQicullt 

II  s'agit  dune  chaine  de  developpement  croise.  installee  sur  un  calculataur  hote  universal  da  la 
serie  VAX.  sous  VMS.  file  comport#  una  certain  nombre  d'outils  programmes  en  FORTRAN  ou  PASCAL,  gui 
permetVent  la  definition  du  logicial  at  la  production  de  code  executable  sur  ALPHA  732  ■■ 

-  Editeur  da  texta 

-  Compilataur  PASCAL 

-  Maero-assamblaur 

-  Editaur  de  liens 

-  64narataur  d' applications 

-  Sibliothague  da  sous -programmes 

-  Simulateur  ALPHA  732 

-  etc. . . 
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CftAcun  tf*  C0S  outils  disposs  dun*  docuAMnt«tioft  compldt*.  ainsi  qu*  dun  j9u  d«  t«$ts.  c*  qui 
«ssur«  s*  m«int«n«piiitd  qt  contribu*  i  s§  port*t>ilit4  sur  unq  ntcbinq  botq  (chpj  i  'tuionnqur  p*r 
qxqmplql . 

Cqttq  cfttSnp  dq  production  logiciollo  ost  ossoeioo  a  un  qnvironnqaiqnt  dq  proqranMation  assurant  unq 
aiqiliqurq  gqation  dqa  dqvqloppq«qnta  : 

’  crqation  qt  gqation  dot  Fichot  d'Incidont  qt  d’rvoiution 

-  Otftii  do  toitio  documontoiro 

-  ote. . . . 

3.2.2  Svstomo  do  Miso  au  point 

Cast  I'outii  dq  basq  dq  la  photo  d 'integration  Matqriqi-Iogicxai.  II  pormot  : 

-  I  'MHiiation  qn  tqaipt  rqql 

-  ia  tqst  qt  la  aMdification  dqa  logiciqis  d ‘application 

-  la  gqnqration  das  antraqa/sortias  do  1  'oquipomont .  s.mujtnt  tinsi  son  or. .  ironnomont  au  sain  du 
futur  aystdaM 

Cat  outil,  pilota  par  un  calculataur  standard  aiicro-VAX  parmat  unq  misq  au  point  rapida  das 
logieials  avae  possibilitas  : 

-  d'obsarvation  sur  points  d'arrat,  an  pas  a  pas 

-  da  visualisation  fina  du  /onctionnaaiant  taa^s  raal,  sans  aucuna  parturbation  du  daroulaaiant  du 
prograama 

L'ansambia  das  moyans  da  dovoloppomont  logiciai  ast  dacrit  dans  la  scbaaia  suivant  ; 
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3.3  ftOYENS  D  IHTEGfiATlQM 

Ces  moyens,  mis  9n  piac«  ch9Z  I'ivionn^ur.  pprm«tt«nt  1' integration  aas  differents  OQuipements .  la 
mise  au  point  du  systeme  au  sol  ot  on  tfol.  puis  la  reception  et  une  eventuelle  certification  de 
1  ' helicoptere  equipe. 

3.].  I  Lts  btnca  d  intiaration 

Les  bancs  d' integration  sont  realises  pour  permettre  1 ' integration  d  ’ une  ou  plusieurs  parties  du 
systeme  au  sol  en  dehors  de  I'helicoptere.  Les  principales  taches  effectuees  sont  : 

-  la  validation  des  cablages 

•  la  validation  des  interfaces  des  equipements 

•  la  mise  au  point  des  dialogues  numeriques  entre  equipements 

-  la  mise  au  point  des  dialogues  avec  les  equipages  /visualisation,  symbologie.  commandos  J 

•  une  premiere  validation  des  fonctions  de  cheque  equipement  par  des  stimulations  statiQues  et 
dynamiques 

-  la  reconstitution  au  sol.  en  utilisant  les  visualisations  de  la  planche  de  bord,  de  certaines 
phases  de  vol  ayant  presente  des  anomalies .  Les  equipes  de  mise  au  point  disposent  ainsi  dun 
moyen  d 'analyse  au  sol  des  pnenomenes. 

Le  banc  d ' integration  mis  en  place  pour  le  developpement  du  systeme  Irlandais  etait  constiCue  : 

-  du  cablage  helicoptere 

-  d'une  generattion  electrique 

-  des  equipements  en  integration 

-  de  ia  pianc^e  de  Pord  epuipee 

-  dun  calculateur  permettarft  de  simuler  en  temps  reel  les  equipements  manquants  et  de  stimuler  le 
systeme  de  maniere  statique  ou  dynamique  en  coherence  avec  des  evolutions  helicoptere 

Le  schema  suivant  illustre  1 ' architecture  de  ce  banc  : 


3.3.2  Las  hilicootir^a 


da  davaloooamant 


Cas  halicoptaras  aquipas  du  systama  sont  d«stin*A  i  misa  au  point  at  i«  v«ii4ation  an  vol  da 
toutas  las  fonctions . 

Flusiaurs  atapas  importantas  sont  nacassairas  : 

~  1 ' intagration  du  systama  dans  I'halicoptara  qui  fait  I'objat  d  un  chantiar  at  d'una  sana  d'assais 
au  soi 

-  la  montaga  d'una  instaiiation  d'assais  compranant  das  aquipamants  da  raferance  at  das  moyans 
d' anragistramant  an  vol 

-  das  vols  d'assais  pour  la  misa  au  point  dafinitiva  at  la  racaption 

-  avantuallamant  das  vois  da  cartification 

Cas  halicoptaras  da  da^aloppamant  pauvant  atra.  soit  das  prototypas.  soit  des  apparails  ‘societa’ 
appartanant  a  I'avionnaur,  soit  l«s  pramiars  apparails  da  sana. 

3.i  OUTILS  DE  GES7I0N  D£  CO^/FlCUBATIfltt 

La  multiplicita  das  fonctions  raalisaas  par  la  systama  antraina .  a  court  tar.nc.  unc  proliferation  da 
versions  diffarantas.  an  particuliar  au  nivaau  du  logicial.  12  deviant  alors  indispensable  da 
disposer  d'outils  da  gastion  das  configurations,  cant  char  la  maltra  d'oauvra  systa/na  qua  char 
1 'equipamantiar.  Cas  ovtils  font  paitia  das  moyans  ganaraux  da  1  entreprisa  et  couvrent  1  ensemble 
des  projats  developpas. 

La  gastion  da  configuration  du  maitra  d'oauvra  gare  las  atats  des  specifications  du  systama  ainsi 
qua  las  fichas  d  evolutions  systama.  L  'aquipemantiar  gere  las  configurations  de  lequipement  qu'il 
realise  an  regard  des  specif ications  de  cot  aquipament  ellas-memes  gerees  par  ia  gastion  de 
configuration  systama  da  I'avionneur. 

4.  CX3HCLUS10H 

Ca  document  prasenta  ies  problamas  qua  posant  la  davaloppamant  d'un  systama  avionique  mooerna  at  las 
solutions  qui  y  ont  ate  apportees  dans  la  cadre  du  projat  DAUPHIN  SAfi  destine  a  1  Irish  Air  Corps. 
Cat  example  mat  an  relief  las  interactions  necetsairas  antra  I'avionneur,  maStra  d  oeuvre  du  systama 
complet.  at  las  sous-  ystemiers  majaurs.  II  souhgne  I'lmportanca  d'una  matnodologie  rigoureuse  dans 
les  echanges  d  informations .  da  la  qualita  desquals  depend  la  bonne  execution  des  travaux.  dans  las 
delais  et  les  couts  impartis.  II  damontra  enfin  la  necessite  de  disposer  de  moyans  adaptes  aux 
differantes  phases  du  projet,  depuis  les  specifications  jusqu  a  la  racaption  de  I'avion. 

Ce  systama  cumule  a  ce  lour  pras  de  f  000  hauras  qa  vol  an  service  ooerationnel  et  donna  toute 
satisfaction . 

Una  talla  experience  constitoa,  pour  Coos  caux  qui  I'ont  acquise.  un  reel  investissement  at  un  gage 
de  reussite  pour  le  developpement  des  systemes  futurs. 

Cependant  la  richesse  fonctionnelle  at  i 'integration  physique  aiiant  croissant,  le  developpement  des 
futurs  systemes  necessitera  une  accentuation  de  1*  demarche  at  one  augmentation  des  moyans. 
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DISCUSSION 


W.R.Fried,  US 

( 1 )  Is  there  any  homing  or  direction-finding  equipment  on  the  helicopter  for  guidance  with  respect  to  the  crash  locator 
beacon  transmissions? 

(2)  Why  is  the  Decca  system  not  used  for  navigation  for  the  Irish  application  * 

Author's  Reply 

( 1 )  There  is  a  beacon  mode  in  the  radar  subsystem.  The  relative  position  of  the  beacon  can  be  transferred  in  the 
navigation  computer.  TTtis  computer  provides  guidance  to  the  location. 

(2)  Tile  Irish  Air  Corps  did  not  choose  this  system  for  its  navigation. 

G.Konainos,  US 

Could  you  please  show  how  the  NADIR  MK2  is  connected  to  and  monitored  by  the  MICROV'.AX  to  pertorm  real-time 
testing  with  no  interference? 

Author's  Reply 

We  cannot  give  you  tex)  many  details.  The  main  point  is  that,  with  the  help  of  a  dedicated  pn^cessor  included  inside  the 
bench,  different  observations  can  be  made  on  the  target  equipment  real-time  functioning  without  any  perturbation  The 
processor  is  never  stopped.  Through  the  connection  U)  various  probes,  three  traces  arc  available:  processor  bus.  input** 
outputs,  and  real-time  tasks  election  description,  all  events  being  dated  })reciscl\ . 
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SUMMARY 


The  unique  operational  and  performance  requireif*^;us  of  the  Communication  Systei.. 
for  modern  tactical  Army  helicopters  are  described.  An  integrated  system  architecture  is 
described  which  satisfies  these  requirements  and  incorporates  very  high  levels  of  automation 
thereby  reducing  pilot  workload.  The  automation  concepts  include  the  ■  of  a  preloaded 
communication  data  base  and  a  centralized  communication  processor  containing  advanced 
control,  reconf iguration  and  message  formatting  software.  Link  analysis  and  simulation 
results  are  presented  which  show  the  performance  capabilities  of  the  system  with  respect  to 
the  projected  mission  requirements. 

INTRODUCTION 


The  Communication  System  of  a  modern  tactical  helicopter  must  satisfy  several 
unique  operational  and  performance  requirements.  Because  of  the  current  trend  toward  single 
pilot  helicopters,  one  of  the  most  important  of  these  requirements  is  low  pilot  workload  for 
operation  of  the  communication  system.  Just  flying  the  helicopter  and  protecting  it  from 
hostile  targets  and  terrain  obstacles  will  keep  the  pilot  very  busy,  so  that  he  simply  will 
not  have  much  time  to  control  and  operate  his  communication  equipment.  This  profem  becomes 
even  more  severe  when  the  helicopter  mission  requires  operation  at  Nap-of -the-Earth  (NOE) 
altitudes,  i.e.,  a  few  meters  above  the  terrain.  The  latter  requirement,  i.e.,  NO! 
operation,  is  also  one  of  the  major  performance  challenges  'or  the  communication  system 
desinn  since  NOE  altitudes  typically  result  ’n  the  non-exJstence  of  1 ine-of -sight  radio 
paths  between  the  communicating  units.  Since  communication  is  a  two-way  process  and  since 
different  military  units  carry  different  types  of  radio  equipment,  interoperability  and 
backward  compatibility  become  very  important  considerations  in  a  communication  system.  This 
paper  describes  an  integrated,  highly  automated,  helicopter  communication  system  designed  to 
satisfy  the  operational  and  performance  requirements  of  future  military  helicopters.  Typical 
operational  mission  requirements  and  unique  performance  requirements  are  first  discussed  in 
some  detail.  An  integrated  system  architecture  is  described,  which  consists  of  several 
different  equipments.  The  automation  concepts  included  in  the  system  architecture  are 
highlighted.  Results  of  link  analyses  and  simulation  runs  for  the  various  systems,  when 
.pt:-‘'ting  in  the  NOE  flight  environment,  are  presented  dod  the  performance  attributes  of  the 
selected  systems  are  described.  Availability  and  reliability  considerations  of  the  system 
are  addressed.  Finally,  the  automation,  integration  and  system  design  characteristics  are 
summarized  and  topics  for  future  research  are  indicated. 

OPERATIONAL  REQUIREMENTS 


The  requirements  for  an  aircraft  or  I.^l'.opt<.r  ccr^unicatio*'  s‘'s*em  can  be 
categorized  into  two  types,  i.e.,  operational  and  peiformance  requirements.  Although  these 
are  frequently  interrelated,  the  operational  requirements  will  first  be  discussed  in  this 
section. 


Perhaps  the  most  critical  operational  requirements  for  the  communication  system 
of  a  modern,  military  helicopter  is  that  it  be  highly  automated  and  simple  to  operate,  in 
order  to  minimize  pilot  workload  and  human  error.  This  is  particularly  important  for  single 
pilot  helicopters.  Currently,  pilots  are  required  to  refer  to  Communication  Electronic 
Operating  Instructions  (CEOl)  books,  to  determine  the  call  signs,  frequencies,  nets, 
authentication  codes,  OPSEC  codes,  etc.,  for  the  particular  time  period,  in  order  to  know  how 
to  call  a  desired  destination  and  what  frequency  or  channel  to  select.  Then,  the  pilot  needs 
to  operate  the  various  controls  which  are  separately  located  on  each  radio  set  and  which 
typically  have  different  characteristics.  These  controls  need  to  be  highly  automated,  so  that 
there  are  very  few  pilot  actions  required  and  these  actions  must  be  simple  and 
straightforward . 

If  communication  is  suddenly  lost,  either  through  a  link  connectivity  failure  or 
a  hardware  failure,  reconfiguration  (I.e.,  change  to  a  different  radio  re’^ou'^ce)  iiust  be 
automatic.  The  pilot  should  merely  be  advised  what  the  system  has  done  for  him. 

Since  the  trend  for  modern  military  operations  is  toward  more  data 
communication,  rather  than  only  voice,  the  entry  of  data  messages  by  the  pilot  must  be  highly 
automated,  as  compared  to  current  practice.  It  is  not  acceptable  for  a  busy  helicopter 
pilot,  partKuia-ly  in  the  middle  cf  cotAbat,  to  use  a  keyboard  to  enter  data,  even  in 
response  to  prompts  appearing  on  displays,  e.g.,  filling  in  required  message  fields.  The 
entire  operation  must  require  very  few  actions  by  the  pilot  and  be  automated  to  a  high 
degree.  A  typical  example  of  such  data  communication  is  the  automated  handoff  of  target  data 
from  one  helicopter  to  another  helicopter,  or  to  a  ground  element. 


Another  Important  operatlona)  requirement  Is  to  have  a  high  probability  that  the 
connunication  link  is  avaiUble  whenever  it  is  needed.  This  implies  high  reliability  of  The 
equipment,  physical  redundancy  of  critical  hardware,  or  functional  redundancy  provided  by 
different  radio  systems.  These  automation  and  availability  require^sents  lead  to  the  need  for 
a  highly  integrated  architecture. 

For  communication  systems,  the  problems  of  interoperabi 1 1 ty  with  fielded 
equipment  and  backward  compatibility  are  of  Importance,  since  the  operation  cannot  be  self 
contained,  like,  say,  certain  navigation  systems.  Thus,  the  design  of  a  future  helicopter 
communication  system  must  consider  the  types  of  equipment  projected  for  fielding  at  all  of 
the  operational  elements  of  Interest,  the  message  formats  and  encryption  systems  used,  and 
such  parameters  as  the  expected  transmitter  power  levels  and  antenna  gains  of  ground  units. 

In  the  future  battlefield,  helicopters  will  spend  a  significant  amount  of  time 
at  NOE  altitudes  so  that  operation  at  these  altitudes  must  be  reliable.  For  self  protection 
reasons,  the  transmitted  signal  level  should  be  as  low  as  possible  and  transmissions  as  s^*ort 
as  possible,  in  order  to  minimize  the  probability  of  intercept  by  hostile  forces.  Modern 
military  cormunication  systems  must  be  able  to  support  both  clear  and  secure  voice  and  data 
traffic,  and  this  traffic  may  be  required  simultaneously  on  several  bands  or  radios.  The 
helicopter  communication  system  should  be  able  to  act  as  a  relay  or  retransmission  platform, 
in  order  to  provide  a  means  for  two  units  who  are  separated  by  too  long  a  range  to 
communicate  with  one  another. 

TYPICAL  MISSION  SCENARIOS 

In  order  to  quantify  the  operational  and  performance  requirements  for  a  typical 
*rmy  helicopter  comniunication  system,  the  results  of  previous  Army  studies,  as  well  as 
certain  projected  mission  scenarios,  were  investigated,  for  example,  Figures  1  and  2  are 
derived  from  data  in  a  U.  S.  Army  Hap-of -the-tarth  Comnunication  Study.  (1).  Figure  1  shows 
the  percentage  of  air-to-air  and  air-to-ground  links  out  of  179  mission-critical  paired 
events  (i.e.,  transmission  and  acknowlegement)  for  an  attach  helicopter  company  operating  in 
the  SCORES  Europe  1,  Sequence  2A  Scenario.  It  is  seen  that  9?X  were  air-to-air  links  and 
only  81  air-to-ground  links.  In  figure  2,  the  data  is  further  b’^oken  down,  showing  the  range 
distribution,  in  percentage,  for  both  the  air-to-air  and  air-to-ground  links.  For  example, 
it  is  interesting  to  note  that  for  the  air-to-air  cases.  91%  of  all  link  ranges  were  less 
than  5Km.  and  12%  were  less  than  ?icm. 

Figure  2  shows  typical  communication  path  lengths  for  a  composite  European 
tactical  scenario.  It  is  seen  that  the  postulated  path  lengths  are  quite  compatible  with 
those  Indicated  on  Figure  2,  thus  correlating  well  with  the  earlier  u.  S.  Army  results. 

Figure  4  shows  typical  anticipated  conmunication  links  based  on  a  projected  battle  team 
flight  configuration.  The  links  represented  in  Figure  4  show  the  need  for  several 
communication  systems  and  nets,  i.e.,  HF-$SB,  VHF-FH,  UHf-A«  and  PJH.  in  order  to  meet 
various  mission  requirements.  For  example.  FM  1  (VHF-FM  Net  No.  1)  and  FM3  represent 
intra-platoon  nets  for  conwnunication  between  the  platoon  over  relatively  short  ranges,  using 
the  VHF -FM  (SINCGARS)  radios.  Communication  between  the  air  battle  captain  and  the  platoon 
leaders  might  be  over  another  VHF-FM  net  or.  if  the  range  requires,  over  an  HF  net  (HFl). 

L^nks  to  the  ground  manuever  units  might  be  over  the  FM2  net.  Links  to  artillery  units,  such 
as  the  fire  support  team  (FIST)  and  the  Fire  Direction  Center  (FDCl  might  be  via  the  djh  net 
or  an  HF  net.  The  UHf  net  will  provide  interoperability  with  the  Air  Force  and  the  HF  2  net 
or  PJh  might  be  for  links  to  the  Tactical  Operations  Center  (TOC)  or  Aviation  Comnand/Control . 

performance  requirements 

Based  on  the  typical  mission  scenarios  discussed  in  the  previous  sections,  the 
major  performance  requirements  of  the  conwwnication  system  for  future  Army  helicopters  can  be 
derived.  Tactical  air-to-air  link  ranges  are  found  to  be  between  2  and  SKM;  typical  tactical 
air-to-ground  ranges  are  of  the  order  of  15Km,  with  some  links  to  rear  ground  elements 
possibly  being  as  much  as  50  to  100  km. 

For  high  priority  tactical  airborne  communications,  it  is  desirable  to  achieve  a 
high  probability  of  successful  communication,  i.e.,  0.9  or  greater. 

Map-of -the-Earth  (NOE)  operation  Is  «  tritital  requirement  and  the  NOE  altitude 
has  been  defined  as  3M  above  the  terrain.  Types  of  terrain  encountered  In  tactical 
operations  range  from  rough,  wooded,  mountainous  terrain  to  more  gentle,  hilly  terrain. 

Ambient  radio  frequency  noue  varies  from  the  moderate  rural  areas  to  the  more  severe  urban 
areas . 

SYSTEM  ARCHITECTURE 


In  order  to  meet  the  operational  and  performance  requirements  described  In  the 
previous  sections,  a  highly  Integrated  communication  system  architecture  was  evolved,  as 
shown  in  Figure  5.  It  includes  a  central  cofTwonicati..'.  processor  which  is  the  "brain"  of  the 
system.  The  processor  software  provides  the  initialization,  control  and  reconf igunlon  of 
all  of  the  radio  functions  and  of  the  audio  control  unit  and  it  also  performs  the  message 
processing  required  fbr  data  <-ommunicatlons .  The  processor  Is  interconnected  to  the  various 
radio  functions  via  local  cnuUipleK  data  busses.  Typically,  two  busses  are  required,  one  for 
control  data  and  one  for  message  data.  The  Contnunications  Processors  acts  as  the  bus 
controller  for  these  local  busses.  As  shown  in  the  figure,  a  centralized  Control/Oisplay  in 


the  crew  station  is  used  by  the  pilot  to  perform  any  comnunication  control  functions.  The 
Interface  between  the  Communication  Processor  and  the  Control/Display,  as  well  as  with  the 
other  avionics  system,  is  via  the  global  avionUs  bus. 

To  meet  the  performance  requirements  outlined  earlier,  a  variety  of 
corrmunication  equipments  are  Included.  Because  of  the  Importance  of  operation  at  NOE 
altitudes,  an  HF-SSB  radio  function  operating  in  the  2-30  MHz  frequency  band  with  ECCM 
capability,  is  included.  The  HF-SSB  radio  will  support  ground  wave  propagation  to  a 
significant  range;  near  vertical  incidence  skywave  (NVIS)  is  applicable  for  medium  range 
requirements  and  normal  skywave  for  the  very  long  ranges.  The  frequency  hopping  (ECCM) 
capability  is  required  to  provide  anti-jam  performance.  The  HF  function  supports  voice  and 
data  traffic  in  both  clear  and  encrypted  modes  of  operation. 

Tlie  VHF-FM  (SINCGARS)  radio  function  operates  in  the  30-88  MHz  band  and  provides 
interoperability  with  a  large  number  of  U.  S.  Army  elements.  It  supports  NOE  operation  to  a 
more  limited  range  than  the  HF  radio.  It  includes  a  frequency  hopping  (ECCM)  mode  to  provide 
anti-jam  performance.  It  has  both  voice  and  data  capability,  at  a  data  rate  up  to  16  Kbps. 

In  the  data  mode,  it  is  compatible  with  the  Army's  TACFIRE  network.  The  VHF-FM  (SINCGARS) 
function  is  included  in  a  dual  redundant  .“anner,  in  order  to  facilitate  simultaneous  dual  net 
operation  and  to  provide  a  retransmission  capability.  In  order  to  enhance  range  performance, 
particularly  at  NOE  altitudes,  a  high  power  VHF-FM  amplifier  is  Included. 

The  VHF-AM  radio  function  operates  in  the  116-152  MHz  band  for  voice 
communication  and  is  included  to  provide  air  traffic  management  and  backup  air-to-air 
capabi 1 ities. 


The  OKF-AM  (HAVE  QUICK)  radio  function  operates  in  the  225-400  MHz  band  and 
primarily  provides  interoperabi 1 ity  with  the  Air  force  for  voice  communication  and  military 
dir  traffic  management  operations.  It  includes  a  frequency  hopping  anti-jam  mode. 

The  PJH  Enhanced  PLRS  User  Unit  (EPUU)  provides  a  highly  jam-resistant,  secure, 
direct  user-to-user  data  communication  capability,  in  conjunction  with  the  PLRS  portion  of 
the  PLRS/JTIOS  Hybrid  (PJH)  network.  It  operates  in  the  420-450  MHz  band  and  uses  two  spread 
spectrum  techniques,  i.e.,  frequency  hopping  and  direct  sequence  spreading,  with  short  burst 
transmissions.  The  PJH  system  also  provides  inherent  automatic  relay  and  net  management 
capabilities.  Optimum  relay  paths  are  automatically  determined  by  the  system,  based  on  link 
quality  measures.  The  EPUU  formats  the  data  used  in  normal  TACFIRE  messages  in  an  efficient 
data  format.  The  current  data  rate  capability  is  1200  BPS  and  is  in  the  process  of  being 
increased  further  through  the  insertion  of  VHSIC  technology.  As  an  example,  PJH 
communications  is  particularly  useful  for  target  data  transfer  from  the  FAAO  to  artillery 
elements,  such  as  the  FIST  and  FOC.  since  the  longer  ranges  required  for  these  links  can  be 
easily  achieved  through  the  PJH  relay  capability.  For  operation  beyond  the  forward  line  of 
troops  (FLOT),  the  high  stability  of  the  EPUU  docks  permits  communication  to  be  maintained 
for  a  long  period,  even  after  connectivity  with  the  PJH  Net  Control  Station  has  been  lost. 
Accurate  position  information  of  all  elements  is  continuously  available  within  the  PJH 
netv-'rk  so  that  the  EPUU  can  provide  own-position  updates  to  the  helicopter's  navigation 
system. 


The  Audio  Control  Unit  (ACU)  routes  the  voice  audio  from/to  the  pilot's 
microphone/headset  and  the  radios.  As  shown  in  the  architecture  diagram  in  Figure  5,  the 
control  of  the  ACU  is  provided  by  the  Communication  Processor  via  the  local  multiplex  control 
bus . 


The  IFF  Transponder  is  included  to  provide  self  protection  of  the  helicopter 
against  attack  by  friendly  forces.  The  IFF  Interrogator  Is  included  so  that  potential 
airborne  targets  can  be  interrogated,  in  order  to  avoid  attacking  friendly  aircraft.  Both, 
the  IFF  Transponder  and  Interrogator  are  also  controlled  by  the  Communications  Processor  via 
the  local  multiplex  data  bus. 

AUTOMATION  CONCEPTS 

One  of  the  primary  goals  of  the  design  of  the  communication  system  was  to 
minimize  the  pilot  workload  associated  with  its  operation.  It  became  clear  that  the  pilot 
should  have  no  involvement  or  very  little  involvement  in  the  initialization,  configuration 
and  (in  case  of  failures)  reconfiguration  of  che  communication  system.  Similarly,  the 
required  pilot  actions  for  entry  of  message  data,  message  formatting  and  message  reception 
should  be  limited  to  as  few  as  possible.  Toward  this  end,  a  maximum  level  of  automation  was 
included  in  the  design  and  these  automation  concepts  a»e  described  in  this  section. 

In  operation,  before  the  start  of  a  mission,  a  communication  pre-mission  data 
base  is  loaded  Into  the  processing  system  memory.  This  data  base  includes  the  electronic 
CEOI  data  applicable  for  the  geographic  area  of  interest,  such  as  the  nets,  frequencies,  call 
signs,  authentication  codes,  OPSEC  codes  for  the  various  Army  organizational  elements,  for 
different  time  period  of  the  day.  In  addition,  the  data  base  will  include  a  mission-unique 
Communication  Plan  (COMM  PLAN),  which  includes  the  units  with  whom  communication  is 
anticipated,  the  primary  and  alternate  radio  bands  and  the  types  of  nets,  such  as  voice  or 
data,  which  are  to  be  used  during  the  mission.  After  appropriate  conversion  to  the  radio 
parameters,  the  Communications  Processor  software  then  automatically  initializes  the  various 
radios  at  the  time  of  takeoff. 
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At  any  time  thereafter,  the  pilot  uses  the  centraliztd  control-display  to 
Initiate  a  comnunlcatlon  event.  For  example,  using  his  display,  the  pilot  may  select  from  a 
matrix  of  symbols,  representing  force  elements,  the  particular  unit  with  which  he  needs  to 
communicate.  Alternatively,  a  voice  command  system  may  be  used  for  this  action.  The 
Coirmunication  Processor  (CP)  software  through  '  se  of  the  pre-stored  data  base,  then  causes 
the  applicable  call  sign,  primary  and  secondary  band  authentication  code,  etc.,  to  be 
displayed  to  the  pilot.  At  the  same  time,  the  CP  automatically  configures  the  primary  radio 
for  the  channel  or  net  applicable  at  that  time.  As  a  result,  the  system  Is  iinned lately  ready 
for  the  pilot  to  initiate  a  voice  transmission.  The  capability  for  a  manual  control  override 
by  the  pilot  must  also  be  available. 

If  the  transmission  of  a  digital  data  message  is  desired,  the  pilot  would 
designate  the  desired  destination  in  the  same  manner  as  described  previously  for  voice 
traffic  and  then  select  the  data  mode  of  operation.  Again,  the  proper  radio  resource  has 
been  selected  and  configured  by  the  software.  The  data  messages  can  then  be  entered  and 
transmitted  In  an  automated  manner.  For  example,  for  a  target  handoff  function,  the  pilot 
merely  initiates  and  commands  the  process  by  selecting  the  redolent  and  the  specific 
target.  The  software  automatically  performs  any  required  coordinate  conversion  for  the 
target  position,  formats  the  required  data  into  the  appropriate  message  format,  (eg.,  the 
TACFIRC  format),  and  routes  the  message  to  the  selected  radio  ever  the  data  bus.  Acknowledge 
processing  is  used  to  sense  any  link  connectivity  failures.  In  case  of  such  a  link  failure 
(for  example  due  to  lack  of  Hne-of -sight) ,  the  software  automatically  reconfigures  the 
system  to  an  alternate  radio  resource.  Similarly,  If  the  built-in-test  (BIT)  functions  sense 
a  hardware  failure  in  a  particular  radio,  the  software  automatically  reconfigures  the  system, 
based  on  the  information  in  the  pre-loaded  COMM  PLAN  and  CEOI  data  base.  The  pilot  is 
informed  (or  alerted)  of  the  reconfiguration  actions  taken  via  his  control-display,  but  he 
does  not  need  to  get  involved  in  any  action.  Thus,  the  automation  concepts  included  in  the 
system  design  provide  for  control  and  operation  of  the  Convnunicatlon  System  with  a  minimlum 
Involvement  by  the  pilot,  therefore  adding  little  to  the  total  pilot  workload. 

PCRFORMANCe  ANALYSIS  RESULT^ 


Link  analysis  and  simulation  runs  were  conducted  in  order  to  determine  the 
performance  of  the  selected  communication  system  with  respect  to  the  mission  scenarios 
described  earlier.  Specifically,  the  achievable  range  performance  of  the  three  primary 
tactical  radio  systems  was  analyzed  as  a  function  of  terrain,  ambient  noise  and  probability 
of  successful  conniunication.  and  the  results  were  compared  to  the  requirements  discussed 
earlier. 


The  link  analysis  and  simulation  effort  made  use  of  the  Transmission  Simulation 
Program  (TSP)  which  had  previously  been  developed  by  Hughes  Aircraft  Company.  It  facilitated 
the  parametric  analysis  of  message  error  rate  versus  link  distances  for  the  various  systems 
being  Investigated,  as  a  function  of  modulation  waveform,  message  structure,  data  rate, 
terrain,  ,etc.  These  data  were  then  used  as  the  basis  for  further  link  analyses,  giving 
achievable  ranges  and  signal  margins,  as  a  function  of  transmitter  power,  antenna  gains  and 
different  link  geometries.  For  most  of  the  analyses,  an  NOE  altitude  of  3m  and  a  probability 
of  successful  commmunication  of  0.9  were  assumed.  Both,  rough  mountainous  terrain  (which 
might  be  typical  of  the  Fulda  gap  in  Germany)  and  more  moderate,  hilly  terrain,  such  as  might 
be  typical  for  certain  mid-east  areas,  were  analyzed.  Urban  ambient  radio  noise  levels  and 
more  moderate  rural  noise  levels  were  treated.  Both  air-to-air  and  air-to-ground 
communication  links  were  analyzed. 

Figure  b  shows  a  comparison  of  achievable  air-to-air  communication  ranges  for 
the  three  primary  tactical  Army  radio  systems  analyzed  versus  a  histogram  of  the  required 
radio  transmissions,  as  derived  from  the  data  in  Reference  1.  It  is  seen  that  all  three  of 
the  systems  will  meet  the  bulk  of  the  required  link  ranges  in  the  worst  type  of  terrain, 
although  HF  radio  out-performs  the  other  two  systems.  Figure  7  shows  a  similar  performance 
comparison  for  the  projected  air-to-ground  links.  For  this  case,  only  HF  radio  and  multi-hop 
(relay)  PJH  links  satisfy  typical  hellcopter-to-arti 1 lery  element  link  ranges. 

Similar  link  analyses  were  performed  for  a  jamming  environment,  but  are  beyond 
the  scope  of  this  paper.  The  results  of  that  analysis  revealed  that  frequency  hopping  (ECCM) 
techniques  are  absolutely  essential  in  HF  and  VHF-FM  radio  systems  in  order  to  provide  the 
required  communication  performance. 

In  summary,  the  results  of  the  performance  analyses  indicate  that  the  selected 
communication  system  meets  the  tactical  range  requirements  for  the  mission  scenarios 
described  earlier.  Use  of  the  higher  available  transmitter  powers  and  use  of  ECCM  in  HF  and 
VHF-FM  radios  are  required.  For  medium  range  requirements,  the  use  of  relay  (for  example 
with  PJH)  or  a  retransmission  mode  will  be  needed.  HF  radio  NVIS  and  conventional  sVywave 
propagation  modes  will  be  used  to  meet  the  longer  range  requirements. 

To  achieve  the  greatest  possible  mission  critical  reliability  performance,  both 
physical  and  functional  redundancy  are  employed.  Examples  of  physical  redundancy  are  the  use 
of  dual  VHF-FM  (SINCGARS)  functions,  dual  power  supplies,  dual  transmitters,  etc.  However, 
use  of  "functional"  redundancy  Is  often  equally  or  more  Important  than  "physical" 
redundancy.  The  reason  for  this  arises  from  the  fact  that  If  the  environment  or 
transmission  medium  have  caused  the  link  to  fall,  redundant  hardware  will  not  solve  the 
problem.  Typical  examples  of  this  are  loss  of  llne-of -sight  due  to  terrain  features  for  VHF 
and  UHF  systems  and  ionospheric  disturbances  or  atmospheric  noise  for  HF  systems. 


CONCLUSIONS 


An  Integrated  helicopter  conmunication  system  has  been  described,  which  is 
highly  automated,  thereby  relieving  the  p  lot  of  the  workload  required  in  current  systems  for 
the  control  and  operation  of  distributed  radios  and  for  the  entry  of  data  messages. 

Link  analysis  results  have  shown  that  the  system  meets  the  operational  and 
performance  requirements  which  have  been  projected  for  tactical  helicopter  mission  scenarios 
of  the  future,  notably  for  operation  at  NOE  altitudes. 

There  are  several  areas  which  deserve  attention  for  future  research  and 
development.  For  example,  in  order  to  ease  field  operations,  a  simple  method  for  centrally 
loading  security  codes  Into  COMSEC  equipment  needs  to  be  developed.  All  of  the 
COMSEC/TRANSEC  functions  should  be  fully  embedded  within  the  radio  hardware  and  effort  is 
required  to  develop  the  interface  and  control  functions  to  accomplish  this. 

Millimeter  wave  radio  equipment  operating  in  the  54-60  GHz  oxygen  absorption 
band  can  provide  a  unique  covert  communication  capability,  i.e.,  an  extremely  low  probability 
of  intercept.  Therefore,  Inclusion  of  that  type  of  system  in  the  future,  either  as  a 
separate  function  or  possibly  as  an  applique  to  another  radio,  should  be  investigated. 
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FIGURE  6.  AIR  TO  AIR  COMMUNICATION  RANGE  PERFORMANCE 
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DISCUSSION 


D.W.Hujisey,  UK 

To  what  extent  are  digital  terrain  elevation  databases  relevant  to  NOB  battlefield  communications,  particularly  with 
regard  to  LOS  prediction? 

Author's  Reply 

The  digital  terrain  elevation  database  could  be  used  in  a  communication  processing  algorithm  to  determine  the 
optimum  radio  band  resource  and/or  the  optimum  relay  paths  to  complete  a  desited  communication  link  to  an  clement. 


G.M.Barling,  UK 

In  your  paper,  you  claim: 

•  Probability  of  successful  communication  is  greater  than  0.9. 

•  The  system  automatically  reconfigured  following  failure  with  no  manual  intervention. 

Does  the  probability  figure  include  an  allowance  for  undetected  failures? 

Author's  Reply 

The  ‘0.9  probability  of  successful  communicadon”  value  was  used  in  the  link  analysis,  from  which  results  were 
presented.  Analysis  has  not  yet  been  made  on  the  effect  of  undetected  failures  on  the  probability  of  successful 
communication. 


M.Kayton,  US 

I  suggest  that  Figures  6  and  7  show  the  number  of  transmissions  per  range  band.  As  it  is,  an  infinite  number  of 
transmission.s  are  called  for. 

Author's  Reply 

The  current  figures  are  intended  to  show  at  which  ranges  required  radio  transmissions  are  most  likely.  They  were 
derived  from  actual  histograms  of  transmissions  in  certain  radio  bands  o  the  type  shown  in  Figure  2. 


J.A.Saimon,  FR 

The  IFF  is  included  in  your  communication  system  (Figure  5).  How  does  it  participate  in  this  system? 

Author's  Reply 

The  communication  proce.s.sing  function  initializes  the  IFF  transponder  and  interrogator  using  preloaded  security  codes 
located  in  the  proces.sing  system  memory.  Power  control  of  both  functions  is  executed  through  the  communication 
processor.  Interrogator  triggering  can  also  be  accomplished  through  the  communication  processing  function. 
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SUMMARY 

Reliable  data  on  the  aircrew‘s  ability  to  acquire  and  process  task -cri t : ca 1 
information  are  of  prime  importance  to  the  design  of  effective  controls  and  displays. 
While  the  available  body  of  psychophysical  research  contains  a  staggering  volume  of 
human  perceptual  and  performance  data  and  principles  that  are  of  potential  value  to 
the  design  process,  these  are  not  systematically  considered  In  the  typical  design  of 
avionics  systems.  Though  the  nature  and  availability  of  these  data  are  a  key  part  of 
this  problem,  it  can  also  be  attributed  to  the  basic  skills  and  Inclinations  of 
designers,  limitations  in  the  available  support  environment,  and  constraints  imposed 
by  the  system  design  and  acquisition  processes. 

Complex  system  design  may  be  characterized  as  a  creative  integration  and/or 
skillful  blending  of  technologies  counterbalanced  to  accomplish  a  predefined  function 
within  material,  cost  and  schedule  constraints.  Design  effectiveness  is  a  function  of 
the  cumulative  "goodness"  of  design  decisions  and  tradeoffs  which  collectively  meet 
design  requirements  within  these  constraints.  System  effectiveness  depends  on  design 
effectiveness  but  may  var  with  changing  demands  and  user  perspectives  in  the  course 
of  system  deployment.  A  common  denominator  in  system  design  is  "information"  and  the 
efficiency  with  which  it  is  factored  into  design  decisions  and  tradeoffs.  The  use  of 
information,  however,  varies  as  a  function  of  its  "perceived"  value  and  cost  (in  terms 
of  risk/time  dollars)  which  may  be  independent  of  its  "real"  value  and  cost. 

The  Integrated  Perceptual  Information  for  Designers  (IPID)  Project  is  a 
multiagency  supported  effort  to  aid  the  accessibility  and  use  of  human  performance 
data  in  system  design.  It  is  formulated  around  five  information  management  objectives 
geared  toward:  1)  Identifying,  collecting,  and  consolidating  human  performance  data 
of  potential  value  to  system  design;  2)  Human  factoring  these  data  to  enable  their 
direct  use  by  system  designers;  3)  Establishing  an  Institute  with  responsibility  for 
maintenance,  update  and  analysis  of  these  resources  to  support  crew  system  design;  4) 
Developing  and  sponsoring  of  educational  opportunities  to  train  and  sensitize  system 
designers  In  the  value  and  application  of  human  performance  data  to  crew  system 
design;  5)  Conducting  exploratory  research  to  define  and  evaluate  requirements  for  an 
automated  design  support  capability  to  aid  designers  to  efficiently  access  and  trade 
off  human  performance  data  with  other  technical  information  germane  to  the  effective 
design  of  crew  systems. 


I.  INTRODUCTION 

Conducting  modern  warfare,  particularly  against  numerically  superior  forces, 
demands  that  Air  Force  research  and  development  programs  support  the  design  of 
avionics  systems  that  are  maximally  effective.  However,  despite  an  infusion  of  new 
display  and  data-hand 1 i ng  technologies  into  fighter  cockpits,  aircrew  workload 
continues  to  be  a  problem.  State-of-the-art  crew  systems  present  a  staggering  volume 
of  codified  visual  and  aural  information  which  competes  for  the  pilot's  attentional 
resources  (see  Figs  1  and  2),  While  few  would  disagree  with  the  contention  that  the 
operator's  ability  to  acquire  and  process  task  critical  information  is  a  major 
contributor  to  system  effectiveness,  the  design  of  crew  systems  has  typically  involved 
little  systematic  consideration  of  human  performance  characteristics  and  limitations. 
While  a  good  deal  of  potentially  useful  human  performance  data  exists,  these  data  have 
had  little  direct  impact  on  the  design  of  crew  system  interfaces.  Though  the  nature 
and  availability  of  these  data  are  a  key  part  of  this  problem,  it  can  also  be 
attributed  to  the  basic  skills  and  inclinations  of  designers,  limitations  in  the 
available  support  environment,  and  constraints  imposed  by  the  system  design  and 
acquisition  processes  (1,  2). 


II.  RELATIONS  BETWEEN  THE  USE  OF  TECHNICAL  INFORMATION  IN  SYSTEM 

DESIGN  AND  DESIGN  EFFECTIVENESS 

Though  human  performance  data  or  other  information  germane  to  a  given  design  must 
exist  before  it  can  be  used,  availability  of  information  is  not  a  sufficient  condition 
to  ensure  its  use.  For  information  to  be  used,  it  must  have  some  perceived  value  or 
relevance  to  the  problem  at  hand.  Domains  of  technical  information  believed  not  to  be 
of  substantive  value  will  not  be  accessed  regardless  of  the  real  value  of  the 
information.  Perceiveo  value,  1n  turn,  is  a  function  of  the  prior  training  and 
experiential  biases  of  the  individual  user. 


22-2 


Independent  of  perceived  value,  the  functional  value  of  pertinent  technical  data 
to  a  given  design  decision  may  be  less  than  that  implied  when  considered  in  a  broader 
system  design  context.  The  design  of  an  aircraft  system  typically  involves  balancing 
tradeoffs  among  many  subsystem  priorities  to  achieve  a  required  "functionality"  within 
material,  cost,  and  schedule  constraints.  Performance  optimiiation  of  the  human- 
avionics  interface  is  but  one  of  many  competing  design  goals.  In  aircraft  system 
design,  other  subsystem  goals  may  take  precedence  in  tradeoffs  with  crew  system 
capabilities.  For  example,  aerodynamic  requirements  will  influence  windscreen  shape 
which  will  determine  crew  system  volume  which,  in  turn,  can  compromise  crew  subsystem 
design  decisions.  Therefore,  satisfying,  rather  than  optimizing,  subsystem  goals  may 
be  optimal  strategy  in  the  context  of  a  qiven  system  design. 

In  practical  terms,  "effective"  systems  are  those  which  operate  efficiently  (i.e., 
perform  the  function  for  which  they  were  designed),  reliably  (i.e.,  minimal 
unpredictable  failures  and  ease  of  supportabi 1 ity) ,  and  competitively  (i.e.,  costs  to 
acquire,  operate  and  maintain  over  the  system  life  cycle).  For  crew  systems,  in  which 
the  human  is  a  vital  component,  operability  (I.e.,  functional  match  betweefi  user  and 
system  capabilities)  and  acceptability  (I.e.,  users  expectations  of  and  willingness  to 
use  the  system)  are  major  factors  contributing  to  a  system’s  "effectiveness." 
Effectively  designed  systems,  therefore,  require  some  consideration  of  the  factors 
which  support  these  attributes. 

Whether  a  given  system  is  perceived  as  "effective"  is  also  driven  by  factors 
outside  of  the  control  of  the  designer  which,  nonetheless^  must  be  planned  for.  To 
the  extent  that  operational  mission  needs  change  and  new  applicable  technologies 
emerge,  systems  become  obsolete  as  a  result  of  their  lowered  operational 
effectiveness.  User  acceptance,  which  may  Itself  be  manipulated  by  marketing  and 
sales  tactics,  will  also  influence  perceived  effectiveness.  In  military  system 
acquisition,  it  is  the  customers  and  end  users  who  define  requirements  :nd  'ontrol  the 
training,  operations,  and  maintenance  environments  which  influence  the  perceived 
effectiveness  of  a  given  system  long  after  it  has  been  designed. 

The  interdependence  among  th-*  myriad  variables  which  contribute  to  the  design  of 
complex  systems,  including  such  behavioral  Intangibles  as  creativity  (3),  makes  it 
difficult  to  predict  the  influence  of  any  single  factor  on  a  given  design.  In 
contrast,  the  pressures  of  limited  time  and  resources  typical  in  system  design  drive 
designers  to  bias  decisions  and  tradeoffs  towards  reduction  of  uncertainty  or  risk. 
Hence.  It  is  not  surprising  that  "new"  crew  systems  typically  are  "adaptive"  designs 
( i .e.  .adapting  a  known  solution  to  a  changed  task)  or  "varient"  designs  (i.e.,  varying 
parameters  such  as  size,  arrangement,  or  timing  of  a  known  design  solution  without 
changing  the  basic  design)  as  opposed  to  "original’’  designs  which  may  depend  on 
untested  approaches  or  technology  (see  reference  4  for  a  discussion  of  "adaptive"  and 
"varient"  designs).  The  selection  of  an  appropriate  baseline  --  a  "proven"  system  or 
subsystem  design  analogous  to  the  one  under  development  --  will  generally  account  for 
the  largest  portion  of  variance  in  a  given  design’s  effectiveness.  In  other  words, 
selecting  a  good  baseline  match  should  reduce  risk  to  system  effectiveness.  Effective 
baselining  of  a  system  design  may  itself  be  constrained  by  a  lack  of  relevant  past 
designs  (e.g.,  prototyping  the  first  lunar  lander),  inaccessibility  of  proprietary 
data,  or  corporate  biases.  As  a  system  design  strategy,  baselining  is  employed  in  one 
form  or  another  throughout  system  and  subsystem  levels  within  any  given  design. 

Theoret 1 ca 1 ly ,  "original"  design  decisions  should  then  precipitate  from  consideration 
of  those  aspects  of  the  baseline  which  are  either  not  responsive  to  current  system 
requirements  or  are  not  effective  In  meeting  these  requirements.  However,  it  is  often 
the  case  in  military  system  acquisition  that  system  requirements  and  design  decisions 
are  biased  toward  potential  opportunities  posed  by  the  availability  or  near- 
availability  of  new  technologies  which,  in  turn,  adds  risk  to  achieving  design 
effectiveness.  Effective  design,  therefore,  involves  a  skillful  blending  of  past 
baselines  with  new  decisions  and  tradeoffs,  counterbalanced  to  minimize  risks  to 
achieving  predefined  functionality  within  material,  cost  and  schedule  constraints. 

Raising  the  efficiency  with  which  information  is  considered  and  factored  into 
design  decision-making  should,  by  Inference,  raise  the  probability  of  "design 
effectiveness."  Conversely,  design  decisions  made  without  consideration  of 
potentially  leveraging  information  may  be  sub-optimal  and  may  collectively,  depending 
on  their  impact  on  system  function,  undermine  design  effectiveness  (1).  Ironically, 
enhancing  design  effectiveness  by  improving  designer  access  to  and  utilization  of 
design  relevant  information  may  be  hampered  by  the  fact  that  designers  are  already 
deluged  by  too  much  information  competing  for  their  time  and  attention.  Given  these 
conditions,  desiqners  will  seek  new  information  only  to  the  extent  that  it  has  high 
perceived  value  (i.e.,  may  reduce  risk)  and  low  perceived  cost  in  terms  of  the  time 
and  resources  to  acquire  and  Interpret  (5),  In  other  words,  it  is  unlikely  that 
additional  information  will  be  sought  beyond  that  perceived  as  satisfactory. 

Hence,  the  design  of  controls  and  displays  effectively  matched  to  the  capabilities 
of  the  pilot  is  dependent  on  a  complex  set  of  factors  bearing  on  the  access  to, 
handling  of,  and  decision  making  with  information.  To  the  extent  that  sound  data 
exist  and  are  used,  these  may  enhance  the  probability  that  a  given  system  will  be 
effective,  though  this  can  never  be  fully  assured.  In  this  context,  designing  for 
design  effectiveness  Implies  aiding  the  accessibility  and  use  of  information  in  design 
dec  1 s 1  on  making. 


III.  A  CONCERTED  AHPPnACH  TO  DESIGN  INFORMATION  MANAGEMENT:  THE  INTEGRATED 
PERCEPTUAL  INFORMATION  FOR  DESIGNERS  PROJECT 

Recognizing  the  need  to  improve  ef  f  ect  i  vene<;<i  of  the  human-avionics  interface  in 
crew  systems,  the  Harry  6,  Armstrong  Aerospace  Medical  Research  Laboratory  set  up  a 
project,  in  1980,  to  develop  a  sound  theoretical  and  empirical  basis  for  human- 
centered  crew  £yscr-.T.  design.  The  p’^incipal  assumption  of  thi*  piujeut,  as 

TACDEP  (Tactical  Aircraft  Cockpit  Development  and  Evaluation  Program),  is  that  crew 
system  effectiveness  ultimately  depends  on  optimizing  the  match  between  the  bandwidth 
of  controls  and  displays  and  the  sensory,  perceptual  and  cognitive  characteristics  of 
the  human  operator.  While  this  assumption  is  difficult  to  prove,  it  is  a  reasonable 
inference  based  on  lessens  learned  from  operability  and  workload  problems  reported  in 
fielded  systems  and  accident  investigations.  In  addition,  though  it  is  generally 
agreed  that  the  operator's  ability  to  acquire  and  process  task  critical  information  is 
a  key  contributor  to  system  effectiveness,  few  resources  exist  to  support  designing 
for  these  operator  functions.  Existing  data  of  potential  value  to  design  are  widely 
scattered  and  difficult  to  discriminate  within  the  voluminous  research  literature. 
Furthermore,  even  with  germane  data  in  hand,  it  may  be  difficult  for  nor.  specialists 
to  assess  the  data's  relevance  to  their  problem  (1).  The  problem  is  further 
exacerbated  by  the  low  perceived  value  of  these  data  by  the  design  community  which  is 
fueled  by  both  negative  experiences  with  these  data  (6,  7)  and  the  pressure  to  account 
for  a  myriad  of  other  system-related  variables  in  the  course  of  crew  system  design. 

Based  on  this  characterization  of  the  problem,  the  Integrated  Perceptual 
Information  for  Designers  (IPID)  project  was  set  up  to  support  TACDEP.  IPID  is  a 
multi-agency  effort  supported  by  organizations  within  the  U.S.  Air  Force,  Army,  Navy, 
and  NASA.  Its  prime  objective  is  to  provide  “high-value"  human  performance  data  as  a 
"low-cost"  resource  to  designers  of  operational  crew  systems  and  traititng  uevices. 

The  project  is  organized  around  five  interrelated  Information  management  and  product 
object i ves : 

1)  Consol  iddtion  of  potentially  useful  Lu.iian  performance  data; 

2)  Presentd t Ion  of  these  data  in  a  form  useful  to  system  designers; 

3)  Real-time  support  for  Analysis  of  the  existing  data  with  respect  to 
system  design  problems; 

4)  Training  and  sens i t i zat i on  of  system  designers  of  the  value  and  use  of  human 
performance  data  in  system  design; 

5)  Support  Accessibility  and  application  of  human  performance  data  in  context 
with  other  design  relevant  data. 

Collectively,  these  objectives,  discussed  in  detail  below,  are  aimed  at  raising 
the  perceived  value  and  lowering  the  perceived  cost  of  using  human  performance  data  in 
system  design. 

1.  CONSOLIDATION 

The  first  objective  of  the  project  was  to  identify,  collect,  and  consolidate  the 
existing  human  performance  data  of  potential  value  to  the  design  of  operator  control 
and  display  interfaces.  This  Involved  the  design  and  development  of  a  professional 
level  reference  work  involving  detailed  treatment  of  forty-five  subject  areas  (see 
Table  1)  by  over  sixty  recognized  experts.  The  resulta.'t  Handbook  of  Perception  and 
Human  Performance  (Boff,  Kaufman,  and  Thomas,  Eds;  8,  9)  Is  a  two- volume  work  of 
approximately  2800  pages.  The  Handbook  differs  from  standard  texts  in  its  emphasis  on 
self-contained  units  of  Information,  detailed  indexing  and  cross-referencing.  It  is 
illustrated  with  over  1600  figures  and  makes  extraordinary  use  of  data  functions  and 
schematics  to  present  technical  material.  Data  are  plotted  in  standard  units  based  on 
the  Systeme  Internat i ona  1  e  (10).  Figures,  tables,  and  their  captions  are  designed  to 
"stand  alone"  so  as  to  be  interpretable  independently  of  the  text.  For  example,  the 
captions  provide  a  description  of  variables  evaluated  in  the  reported  study,  an 
indication  of  the  data  reliability,  a  "bottom  line"  summary  of  what  the  data  are 
about,  and  a  reference  giving  the  source  of  the  data.  While  the  intended  user  of  the 
Handbook  is  the  ergonomist  or  RiO  engineer,  it  provides  a  reliable  basis  for 
subsequent  products  of  more  direct  design  relevance. 


Table  1  -  Handbook  Table  of  Content; 


Section  I:  THEORY  AND  METHODS 

1.  Psychophysical  Measurement  and  Theory 

2.  Strategy  and  Optimization  in  Human  Information  Processing 

3.  Computer  Graphics 
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Tab^e  1  -  Handbook  Table  of  Contents  -  Continued 
Section  II:  BASIC  SENSORY  PROCESSES  I 

4.  The  Eye  as  an  Optical  Instrument 

5.  Sensitivity  to  Light 

6.  Temporal  Sensitivity 

7.  Seeing  Spatial  Patterns 

8.  Colorimetry  and  Color  Oi scr imi nat ion 

9.  Color  Appearance 

10.  Eye  Movement 

Section  III:  BASIC  SENSORY  PROCESSES  II 

11.  The  Vestibular  System 

12.  CutareoLS  Sensitivity 

13 .  K 1  nesthes 1  a 

14.  Audition  I:  Stimulus,  Physiology,  Thresholds 

15.  Audition  II:  Loudness.  Pitch,  Localization,  Aural  Distortion,  Pathology 
Section  IV:  SPACE  AND  MOTION  PERCEPTION 

16.  Motion  Perception  in  the  Frontal  Plane:  Sensory  Aspects 

17.  Perceptual  Aspects  of  Motion  in  the  Frontal  Plane 

18.  The  Perception  of  Posture,  Self  Motion,  and  the  Visual  Vertical 

19.  Motion  In  Depth  and  Visual  Acceleration 

20.  Visual  Localization  and  Eye  Movements 

21.  Space  Perception 

^2.  Representation  of  Motion  and  Space  in  Video  and  Cinematic  Displays 

23.  Binocular  Vision 

24.  Adaptation  of  Space  Perception 

25.  Intersensory  Interactions 

Section  V:  INFORMATION  PROCESSING 

26.  Auditory  Information  Processing 

27.  Speech  Perception 

28.  Visual  Information  Processing 

29.  Perceiving  Visual  Language 

30.  Motor  Control 

Section  VI:  PERCEPTUAL  ORGANIZATION  AND  COGNITION 

31.  Tactual  Perception 

32.  Auditory  Pattern  Recognition 

33.  The  Description  and  Analysis  of  Object  and  Event  Perception 

34.  Spatial  Filtering  and  Visual  Form  Perception 

35.  Properties,  Parts,  and  Objects 

36.  Theoretical  Approaches  to  Perceptual  Organization 

37.  Visual  Functions  of  Mental  Imagery 

38.  Computational  Approaches  to  Vision 

Section  VII:  HUMAN  PERFORMANCE 

39.  The  Effects  of  Control  Dynamics  on  Performance 

40.  Monitoring  Behavior  and  Supervisory  Control 

41.  Workload:  An  Examination  of  the  Concept 

42.  Workload  Assessment  Methodology 

43.  Vigilance,  Monitoring,  and  Search 

44.  Changes  in  Operator  Efficiency  as  a  Function  of  Environmental  Stress,  Fatigue, 
and  Circadian  Rhythms 

45.  The  Model  Human  Processor;  An  Engineering  Model  of  Human  Performance 


2.  PRESENTATION 

This  second  objective  is  concerned  with  development  of  an  approach  to 
communicating  ergonomics  data  to  system  designers  who,  while  having  little  prior 
training  and  experience  with  ergonomics,  need  reliable  data  to  support  design 
decisions  or  tradeoffs  between  human  performance  and  equipment/environmental 
considerations.  The  Engineering  Data  Compendium  (11)  Is  d  reference  document  which 
consolidates  human  sensory/perceptual  and  performance  data  in  a  form  human-factored 
for  system  designers.  It  provides  comprehensive  and  detailed  specifications  on  the 
caDabilities  and  limitations  on  the  human  operator,  with  special  emphasis  on  those 
variables  which  affect  the  operator’s  ability  to  acquire,  process,  and  make  effective 
use  of  task  critical  information. 

Information  was  selected  for  inclusion  into  the  Compendium  on  the  basis  of  its 
practical  potential  for  system  design  through  an  iterative  process  of  review  and 


analysis  employing  hundreds  of  technical  subject  matter  experts  and  "designers." 
Prospective  entries  were  reviewed  on  the  basis  of  statistical  and  methodological 
reliability,  applicability  to  the  normal  adult  population,  and  potential  relevance  to 
design  problems.  The  Compendium  consists  of  approximately  1200  concise  two  page 
entries  (see  Figure  3)  designed  to  be  self-contained,  with  information  from  related 
studies  summarized  and  presented  in  graphic  form  wherever  possible.  Entries  have  been 
prepared  treating  parametric  data,  models  and  quantitative  laws,  principles  and 
nonquantitative  laws.  Expected  to  be  published  by  the  Air  Force  (11),  it  will  consist 
of  four  volumes  --  three  looseleaf  volumes  of  perception  and  performance  data  and  a 
bound  User's  Guide  containing  supplementary  aids  such  as  instructions  for  locating  and 
using  individual  entries,  design  checklists,  indexes,  and  a  glossary.  Specific 
programmatic  details  of  this  effort  are  summarized  In  Reference  12. 

3.  ANALYSIS 

In  conjunction  with  the  Tri-Services  and  NASA,  the  Harry  G.  Armstrong  Aerospace 
Medical  Research  Laboratory  will  establish  and  host,  beginning  in  1988,  a  Crew  System 
Ergonomics  Information  Analysis  Center  (CSERIAC).  CSERIAC  will  provide  a  full  range 
of  technical  information  services  in  support  of  crew  systems  research,  design,  and 
development  in  the  government,  industrial  and  academic  sectors.  The  essential  mission 
of  CSERIAC  is  to  maintain  contact  with  the  relevant  knowledge  and  experience  bases 
across  th<»ce  to  develop  ti«e  ability  ana  media  to  draw  upon  and  focus  this 

'expertise  to  solve  problems,  achieve  expert  consensus  and  aid  planning  for  more 
effective  use  of  ergonomics  data  in  the  system  design  process.  In  addition,  CSERIAC 
will  provide  information  services,  including  topical  reviews,  special  analysis 
reports,  data,  models,  design  support  software,  methodological  assistance  and  a 
"Current  Awareness"  newsletter.  Maintenance  and  update  of  data  bases,  including  the 
I P I D  Engineering  Data  Compendium  will  also  be  a  function  of  CSERIAC. 

To  determine  the  validity  of  the  need  for  a  DOO  center  devoted  to  the  analysis  and 
dissemination  of  crew  system  ergonomics  Information,  3705  potential  users  within  DOD 
and  industry  were  surveyed  by  a  mail  questionnaire  (13).  Eighty-seven  percent  {87%) 
of  the  829  respondents  agreed  that  a  Department  of  Defense  CSERIAC  was  the  appropriate 
mechanism  to  meet  this  need.  Seventy-nine  percent  {79%)  of  the  respondents  work  'n 
research  and  development,  management  or  design.  Ninety-seven  percent  (97%)  use  crew 
systers  ergonomics  information.  Seventy-eight  percent  {78%)  are  willing  to  pay  fees 
for  CSERIAC  services.  Over  4000  requests  per  year  for  CSERIAC  services  would  be  made 
by  the  survey  respondents  alone. 

The  major  initiating  task  for  CSERIAC  will  be  to  achieve  the  credibility  and  aura 
of  a  "center  of  excellence"  capable  of  attracting  the  range  of  professional  support 
across  the  international  community  essential  to  its  usefulness  and  long-term 
survivability, 

4.  TRAINING 


This  objective  of  the  project  is  to  enhance  the  perceived  value  and  demonstrate 
the  app  1  i cab  1 1  i ty  of  ergonomics  data  for  system  designers  through  a  series  of 
educ a t  i ona  1 /tra i  n  i  ng  opportun i  t  i es .  Tl.c  Hrst  of  a  proposed  series  of  short  courses 
and  seminars  vas  conducted  under  the  auspices  of  the  University  of  Dayton  in  Dayton, 
Ohio  during  8-13  June  1986.  Offered  as  the  "Human  Perception  and  Performance  Workshop 
for  System  Designers,"  its  primary  goal  was  to  provide  system  designers  with  a  human 
performance  framework  for  “decomposing"  equipment-related  design  problems  while 
sensitizing  participants  to  the  Issues  and  approaches  in  using  human  performance  data 
in  human-machine  system  design.  Future  training  functions  are  in  planning  and  include 
development  of  ar  AGARO  Lecture  Series. 


5.  ACCESSIBILITY 


The  fifth  information  management  objective  of  the  project  is  to  aid  the 
accessibility  and  application  of  human  performance  data  in  the  context  of  other  system 
des  1  gn -re  1  a  ted  information  and  procedures.  "Designer's  Associate"  is  a  four-year 
exploratory  research  program  to  define  and  validate  functional  specifications  for  a 
"human  engineered"  design  support  system  which  efficiently  services  the  integrated 
technical  information  needs  of  operational  and  training  crew  systems  designers. 

The  program  approach,  illustrated  in  Figure  4,  is  fundamentally  based  on  testing 
IPID  project  assumptions  regarding  problems  and  issues  in  the  handling  of  technical 
information  by  system  designers.  This  has  engendered  the  need  to  develop  an 
Integrated  understanding  of  the  role  and  handling  of  technical  information  in  the 
process  of  designing  operational  and  training  crew  svstems  acres':  Government  and 
'.nduslrial  sectors.  Field  Interviews  with  system  design  personnel  help  to  identify 
common  needs,  problems,  and  perceived  benefits  in  their  use  technical  information 
and  its  implications  for  design  products  (14), 

Information  handling  Issues,  deemed  within  the  scope  of  Designer’s  Associate  (DA), 
are  analyzed  in  terms  of  causes  and  implications.  Based  on  this  analysis,  candidate 
0®  support  functions  and  capabilities  which  have  potential  to  resolve  these  problems 
are  identified;  these  functions  are,  in  turn,  analyzed  to  determine  the  supporting 
technologies  necessary  for  their  Implementation.  Those  functions  which  can  be 
supported  by  current  technology  or  prospectively  supported  by  emerging  technologies 
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(e.g.,  machine  intelligence;  15),  collectively  comprise  the  Designer's  Associate 
system  concept.  This  concept  will  be  validated  and  documented  at  individual  function 
and  integrated  system  levels  through  a  series  of  tests  and  evaluations  involving 
simulation,  laboratory  studies,  field  studies,  interviews  with  designers  and  design 
management,  and  development  of  research  software.  Research  to  advance  "borderline" 
technologies  will  be  supported  in  diverse  areas  including  cross-d i sc i p 1 i nary  access 
and  interpretation  of  technical  information,  decision  aiding,  and  user-system 
interface.  The  final  products  of  the  program  will  be  a  series  of  demonstrations  of 
Designer's  Associate  functions  and  capabilities  and  a  functional  system  specification 
sufficiently  validated  to  support  justification  for  advanced  development. 

Production  of  the  Designer's  Associate  support  system  by  the  mid-1990‘s  should 
facilitate  information  handling  and  decision  making  for  crew  system  designers. 
Designers  will  have  greater  potential  then  ever  before  to  draw  upon  available 
knowledge  resources,  presently  widely  diffuse,  and  focus  these  consistently  into  all 
levels  of  design  decision  making.  This  capability  coupled  with  decision  aiding  and 
advanced  user  interface  technologies  will,  in  turn,  provide  the  power  to  rapidly 
consider  more  alternatives,  more  effectively,  thereby  enhancing  the  p*'obability  of 
system  effectiveness. 


IV.  CONCLUSIONS 

Design  effectiveness  is  the  degree  to  which  system  function  meets  design 
requirements  within  cost  and  schedule  constraints.  It  is  a  function  of  the  cumulative 
goodness  of  design  decisions  and  tradeoffs,  which  are,  in  turn,  dependent  on  the 
information  factored  into  these  decisions.  Serendipity  excluded  (e.g.,  the  resistor 
design  that  makes  a  fine  lightbulb),  design  effectiveness  is  a  necessary  though  not 
sufficient  condition  for  system  effectiveness  which  may  vary  with  factors  outside  of 
the  control  of  the  designer  and  design  process  (i.e.,  changing  demands  or  requirements 
of  the  operational,  maintenance  and  training  environments  in  which  the  system  is 
deployed).  Hence,  while  the  probability  of  system  effectiveness  may  be  enhanced  by 
design  effectiveness,  it  can  never  be  ensured. 

The  products  of  the  IPID  Project  will  support  the  avionics  sys t em  des i gner '  s 
ability  to  match  crew  system  displays  and  controls  to  the  performance  capabilities  of 
the  operator.  The  Handbook  of  Perception  and  Human  Performance  (8,  9)  and  human 
Engineering  Data  ComFendium  (ll)  consolidate  and  package  these  data  in  a 
comprehensible  format.  CTfRIAC  will  provide  access  to  the  state-of-the-art  in  crew 
system  ergonomics  through  interactions  with  current  experts  and  analysis  of  th«, 
literature.  It  will  influence  both  the  definition  of  requirements  and  the  details  of 
design  necessary  to  accomplish  them.  Professional  short  courses,  conferences,  and 
symposia  will  sensitize  and  familiarize  system  designers  with  the  value  of  these  data 
while  lowering  perceived  risks  in  their  use.  The  Designer's  Associate  support  system 
will  eventually  automate  access  and  utilization  of  these  data  in  the  context  of  other 
relevant  design  information  and  aid  the  designer  to  factor  these  into  design  decisions 
and  tradeoffs,  thereby  contributing  in  a  meaningful  way  to  design  effectiveness. 
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Figure  3  Sample  compendium  entry 
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DESIGN  TOR  INTEROPERABILITY 
(INTERCHANGEABILITY) 

By :  George  KonoBos 
AFVAL/AAAS-3 

URICHT-PATIERSON  AfB,  OHIO  45A33-6543 


I.  ABSTRACT; 

Today  the  technology  has  reached  the  point  chat  aakea  the  coonunlcation  among  varloua 
Bubayatema  eaally  reallxable.  On  Che  other  hand  the  complexity  of  theae  ayatema  la  auch  that  their 
development  la  time  and  coat  demanding.  It  la  natural  therefore  to  dealgn  our  ayatema  Co 
communicate  and  work  with  each  other  and  move  away  from  the  methoda  of  the  paaC. 

Interoperability  of  the  varloua  elcmenca  uaed  In  a  ayatem  la  Che  dealgn  property  which  allowa 
the  Intermixing  of  eleawnta  from  varloua  aourcea  (manufacturera)  without  any  Impact  on  the 
performance  of  the  ayatem  or  the  operational  aoftware. 

One  can  arbitrarily  dlatlngulah  at  leaat  three  levela  of  Interoperability. 

a.  Line  Replaceable  Unit.  Although  we  are  moving  away  from  chla  architecture,  the  LRD  approach 
requlrea  a  RADAR  to  uae  any  Interoperable  computer  rather  than  the  one  built  by  the  RADAR 
manufacturer  Juat  for  that  purpoae. 

b.  Line  Replaceable  Module.  Thla  la  the  new  approach  to  avlonlca  where  a  proceaaor  nodule  la  a  6" 

X  6"  plug-ln  board  with  proceaalng  power  many  tinea  higher  than  that  of  older  LRDa.  If  It  la  In  its 
Infancy  we  certainly  can  dealgn  theae  modulea  Co  be  Interchangeable  no  natter  who  nanufaccurea  them. 

c.  VHSIC  chip.  Thla  la  the  loweaC  level  of  neanlngful  Interoperability.  The  varloua  VIISIC 
developera  have  agreed  to  dealgn  their  producta  "Interoperable"  with  each  other. 

Thla  paper  deala  with  the  aecond  type.  It  la  a  caae  atudy  of  the  two  VHSIC  computera  we  ace 
now  developing.  He  plan  to  uae  modulea  from  two  manufacturera  to  conatrucc  a  amall  avionic  ayatem 
and  then  replace,  both  phyalcally  and  electronically,  any  one  of  the  modulea  with  another  made  by 
Che  ocher  manufacturer. 


II.  SOME  IMPORTANT  CONCEPTS; 

It  la  difficult  to  Imagine  Interoperable  modulea  without  really  meaning  Interchangeable.  In 
effect,  we  mean  modulea  which  can  be  n^e  by  varloua  manufacturera  and  be  able  to  be  uaed 
Indlacrlmlnately  In  an  avlonlca  ayatem.  Some  of  theae  Idcaa  were  originated  by  the  alrllnea.  They 
demanded  that  any  one  can  build  a  radlo-coMuinlcatlona  "box"  aa  long  aa  It  could  be  uaed  In  the 
airplane  environment.  That  waa  a  almple  one.  The  only  thing  one  had  to  worry  about  waa  the  alte, 
power  and  the  radio  frequenclea  It  covered.  Later,  however,  equipment  became  more  complicated  and 
had  aK)ca  than  a  couple  parametera  which  Interfaced  with  each  other  or  the  environment.  The  Inertial 
navigation  act,  for  example,  needed  aome  other  input  auch  aa  Initial  valuea.  Eventually  the 
alrllnea  wrote  apeclflcatlona  for  purchaalng  thla  kind  of  equipment.  Either  becauae  they  were  very 
smart  and  could  dlatlngulah  the  Important  from  the  non-lmportant  parametera  nr  becauae  they  were  not 
smart  enough  to  apeclfy  manufacturing  detalla,  the  reaulc  waa  that  theae  apeclflcatlona  were  short 
and  simple.  The  military,  on  the  other  hand,  was  faced  with  the  problem  of  developing  special 
equipment  which  was  not  commercially  available  or  had  no  uae  outside  the  military.  The  Heads  Up 
Display  (HUD)  la  such  an  example.  Mainly  because  of  these  conditions,  the  military  specifications 
became  "development"  specifications  and  gradually  became  more  and  more  complicated.  But 
interoperability  does  not  deal  with  the  manufacturing  processes  or  the  properties  of  the  particular 
components  used.  Instead,  it  deals  primarily  with  the  visible  by  the  user  Interfaces  and 
performance  characteristics  which  Impact  the  rest  of  the  system.  He  have  attempted  to  have  all  this 
type  of  Information  In  one  document  called  "Functional  and  Interface  Specification."  The  first  one 
has  been  Issued  In  cooperation  with  the  two  VHSIC  MIL-STD-1750A  module  manufacturers  and  two  users, 
system  manufacturers. 

In  the  case  of  the  new  "modular"  electronics  where.  In  fact,  a  "module"  has  hundreds  of  times 
the  performance  of  an  older  "box"  or  LRU,  the  problem  Is  vary  Interesting.  There  are  those  who 
Insist  that  tbs  communications  of  such  modules  should  be  kept  at  very  high  level,  thus  simplifying 
the  electrical  aiul  protocol  problems  of  the  connecting  bus.  Yet  there  are  others  who  Insist  that 
thla  type  of  module  can  operate  efficiently  In  a  very  tightly  coupled  syatam  where  each  module  la 
considered  to  be  an  extension  of  the  other  with  extreme  psrallellsm,  reconfl-  guratlon  and  fault 
tolerance.  Tha  second  approach  has  been  chosen  for  the  first  attempt  of  tasking  "modular" 
electronics  Interoperable  and  Interchangeable.  In  fact,  the  first  such  nodules  well  defined  at  this 
time  are  the  V1750A  CPU  modulea  provided  with  four  channels  of  communications,  namely;  two 
Fl-busas,  ona  TM-bus  and  one  IEEE-A88  bus.  The  above  mentioned  Functional  and  Interface 
Specification  reflects  this  definition. 

An  avionic  system  Is  comprised  of  s  sec  of  sensors  and  transmlttets  to  evaluate  and  coanunlcate 
with  Che  aircraft's  environment.  These  subsystems  are  connected  to  soma  type  of  data  processora 
which  manipulate  Information  from  and  to  sensors  and  tranamlttars.  The  processors.  In  turn,  are 
connected  to  displays  or  othsr  Input/output  devicse  for  convantent  man-machine  Interface.  Although 
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It  would  be  Ideal  If  interoperability  would  apply  to  all  the  componenta  of  an  avionic  system,  we 
will  limit  our  discussion  only  to  the  proceasors.  For  this  purpose,  interoperability  implies 
"physical  or  electronic  replacement  of  one  processor  module  with  another  without  any  Impact  on  the 
Operational  Flight  Program  (OF?)."  It  is  important  to  understand  that  the  only  restriction  we  would 
have  to  apply  to  the  OFF  is  that  it  must  not  Include  software  timing  code  sequences  or  fault 
diagnostic  routines  dealing  with  hardware  below  the  module  level.  These  are  not  severe 
restrictions.  Hardware  timers  are  available  on  the  modules  and  In  an  operational  situation  it  is 
not  necessary  or  important  to  isolate  a  fault  to  a  particular  capacitor.  It  is  sufficient  to 
Isolate  the  fault  to  a  module  and  then  electronically  remove  It  from  the  operation  and  perform  its 
function  in  another  interoperable  module. 

This  type  of  interoperability  implies  the  following  conditions: 

a.  All  modules  must  be  dimensionally  identical.  This  is  necessary  to  support  "physical" 
replacement. 

b.  All  modules  must  have  identical  electrical  Interfaces.  This  also  is  necessary  to  support 
"physical  replacement." 

c.  All  modules  must  have  identical  Instruction  Set  Architecture  (ISA).  This  is  necessary  to 
support  the  electronic  replacement. 

The  first  two  requirements  are  easy  to  understand.  After  all  we  are  used  to  the  idea  of  replacing 
one  voltmeter  with  another.  It  must  fit  in  the  existing  mounting  hole  and  must  cover  the  same 
scales.  But  why  do  we  need  to  have  the  same  ISA  in  the  modules?  Doesn't  that  imply  identical 
hardware?  Doesn't  Ada  make  the  differences  in  the  ISA  invisible  to  the  programmer? 

The  answer  to  the  second  question  Is  "no."  Vie  have  many  implementations  of  the  MIL-STD-WSOA  ISA. 
Each  Implementation  uses  very  different  hardware.  Yet  they  all  pass  the  software  test  we  provide  at 
WPAPB  (MIL-STD-1750A  validation). 

The  answer  to  the  first  question  requires  some  assumptions.  For  example  we  must  assume  that  our 
Interoperable  modules  operate  in  a  tactical  fighter  where  "real  time"  is  at  a  premium.  "Real  time 
reconfiguration"  is  necessary  and  must  be  accomplished  at  the  minimum  time  possible.  With  such  an 
assumption  it  becomes  obvious  that  software  programs  must  be  stored  In  their  "machine  executable" 
form.  We  can  not  afford  to  atore  a  program  in  its  source  form  then  compile  it,  link  it  and  load  it 
In  a  module  while  the  fighter  aircraft  la  in  a  high  speed  maneuver.  In  other  words,  software  load 
ffiodulea  must  be  stored  In  absolute  machine  code  and  ready  for  execution  In  any  of  the  interoperable 
modules.  This  requirement  of  extreme  efficiency  in  an  operational  environment  demands  Identical 
ISAs  in  all  processors  within  the  same  avionic  system. 


Ill .  SOWE  CAHDIPATF  STANDARDS 

In  order  to  support  this  type  of  interoperability,  the  adoption  of  standards  is  necessary.  In 
addition  to  MIL-STD-1750A  ISA,  the  MIL-STD-Ib53B  and  the  IEEE  STD  488,  the  following  should  be 
considered  as  standards  if  interchangeabllty  is  to  be  taken  seriously. 

a)  The  Pi-Bus. 

The  PI“bua  version  we  have  adopted  is  a  16  parallel  bit,  linear,  multi-drop,  synchronous  bus  which 
supports  digital  communications  between  up  to  32  modules  on  a  single  backplane. 

The  bus  uses  a  master-slave  communications  protocol  «diich  allows  the  bus  master  to  read  data  from 
one  slave  or  write  data  to  any  number  of  slaves  In  a  single  message  sequence.  Messages  may  be 
routed  to  particular  modules  using  either  logical  or  physical  addressing.  A  number  of  Independent 
messages  may  be  transmitted  during  a  bus  master’s  tenure.  The  message  formats  provide  s  32  bit 
virtual  address  range  for  each  module. 

The  Pi-bus  protocol  specifies  a  set  of  bus  state  transitions  which  control  the  comDunlcatlon 
sequences  and  allow  the  bus  to  operate  In  a  pipelined  manner  at  the  maximum  clock  rate  allowed  by 
the  bus  signal  propagation  delay.  Master-slave  handshaking  is  provided  with  a  minimal  performance 
penalty  by  operating  Che  slave  modules  in  synchronism  with  the  master  and  using  bus  state 
look-ahead . 

The  bus  provides  a  technique  for  temporarily  suspending  low  priority  block  data  cranafera  thus 
reducing  bus  acquisition  latency  for  higher  priority  messages. 

The  bus  mastership  may  be  changed  either  by  direct  assignment  or  by  priority  arbitration.  There  are 
128  logical  levels  of  message  priority  and  32  levels  of  physical  priority. 

Extensive  signal  line  and  sequence  error  detection  capability  is  incorporated  Into  the  bus 
definition.  In  addition,  an  optional  single  line  error  correction  capability  is  specified. 
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b)  The  TM~Bu6. 

The  Test  and  Kalntenance  (TH)  bus  is  s  staple,  serisl,  linear,  aultidrop  coonunlcations  back-panel 
bus  between  a  'MASTER*  aodule  and  up  to  32  'SLAVE*  aodules  residing  In  the  saae  backplane.  It 
operates  with  a  clock  of  up  to  6.25  KHZ.  There  are  four  signal  types  okaklng  the  TM  bus. 

1)  The  clock,  usually  originating  in  a  systea  clock  aodule,  separate  than  the  master  nodule, 

2)  TM-naster  data,  a  single  unl-directional  line  used  to  transmit  from  the  master  the  address. 
Instruction  data,  scan  data  etc.  to  Che  slaves, 

3)  Slave  data  line  for  the  slaves  to  eranaait  acknowledgments,  data,  and  interrupts  to  the  master, 
supporting  wlred-OR  configuration,  and 

4)  Control  signal  unidirectional  from  the  master  to  slaves  Indicating  DATA  TRANSFER  state  when 
asserted  or  IDLE  when  released. 

This  bus  Is  the  coapanlon  of  the  Pl-bus  and  uses  most  of  the  characteristics  of  it,  including  a 
derived  clock. 


Performance  Characteristics 

6.25  MHz  clock  (Typical) 

4  pin  bus  signal 
Synchronous  Operation 

Two  Data  Lines 
SLAVE  status  register 


Protocol  Characteristics 

8  reserved  address  bits 
32  module  addresses  {maximum) 
8  sub-addresses  per  module 
address 

Multi-drop  Configuration 
Interrupt  Capability 


c)  In  addition,  the  DMA  control  and  data  structures  aa  well  as  the  XIO  commands  necessary  for 
Interfacing  the  MIL-STD-17S0A  processor  and  Its  memory  with  the  PI  and  TM  buses  as  well  as  the 
MIL-STD-t553B  and  the  high  apeed  data  bus  electronics  should  be  considered  for  standardization. 


VI.  CONCLUSIONS. 

The  processor  part  of  an  avionic  system  is  shown  in  figure  1.  Various  types  of  nodules  are 
interconnected  to  form  a  cluster  and  then  these  clusters  are  Interconnected  with  the  high  speed  data 
bus. 

Based  on  our  discussion,  we  have  reached  the  conclusion  that  an  avionic  system  can  be  built  based  on 
interoperable  modules  shown  In  figure  1.  Each  module  Is  a  processor  with  the  left  side  I/O  fixed. 
This  Includes  two  Pl-buses,  one  TM-bus  and  the  IEEE'<«d8  bus.  We  have  made  the  right  side  variable 
CO  accammodace  present  and  future  external  cluster  Interfaces,  yet  we  keep  the  ISA  part  fixed. 

To  support  this  type  of  Avionic  System  we  must  accept  the  internal  architecture  of  each  module  to  be 
that  sho%m  in  figure  2.  This  module  requires  for  the  left  hand  (BIU)  interface  five  XIO  commands 
and  a  DMA  data  structure.  Similarly  the  right  hand  interface  requires  a  number  of  XIO  and  Identical 
DMA  data  structure. 

Using  exclusively  this  type  of  Interoperable  modules  one  can  construct  a  high  performance  avionic 
system  to  acconimodate : 

a.  Fast  real  time  reconfiguration  -  Any  module  can  be  electronically  added  or  subtracted  from  the 
system. 

b.  Maximum  fault  tolerance  -  Failed  module  can  be  electronically  replaced  by  another,  or  at  the 
worst  case,  Its  function  can  be  moved  to  another  module. 

c.  Graceful  degradation  -  If  remaining  functioning  modules  can  not  perform  all  of  the  required 
functions,  then  functions  of  lesser  importance  can  be  eliminated.  The  functioning  modules  can 
be  assigned  to  perform  the  more  important  functions. 

d.  Simplified  on  line  maintenance  -  Modules  have  been  designed  for  easy  physical  replacement  on 
the  aircraft.  Because  of  their  much  smaller  volume  and  weight,  the  "piug-ln"  feature,  the 
visual  fault  Indicators,  and  the  extensive  self^testlng,  there  should  be  no  need  for  highly 
skilled  technicians  to  perform  this  task. 

e.  Economic  operation  -  Avionics  of  various  types  of  aircraft  can  be  based  exclusively  on  this 
type  of  modules  thus  requiring  reduced  stock  piles  of  different  kinds.  In  addition,  the  high 
demand  of  fever  types  of  modules  will  Increase  the  buying  quantities  and  encourage  competition 
thus  lowering  the  price. 
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THE  ELECTROMAGNETIC  THREAT  TO  FUTURE  AVIONIC  SYSTEMS 


BRUNO  AUDONE 

AERITALIA  Gruppo  Equipaggiamenti 
Caselle  Torinese  Torino  (ITALY)  10072 


SUMMARY 

The  electromagnetic  threat  to  future  aircraft  Is  studied  and  evaluated  on  the  basis 
of  th®  evolution  of  the  avionic  systems.  The  high  level  of  integration  of 

these  systems  combined  with  the  increased  number  of  electromagnetic  sources  which  may 
interfere  with  the  performances  of  the  overall  weapon  system  create  the  need  of  reexa 
mining  the  usual  design  and  testing  approach  in  order  to  reach  an  adequate  level  of 
aircraft  hardening  It  is  essential  to  design  and  test  at  system  level  rather  than 
equipment  level:  this  aim,  obviously,  is  difficult  to  achieve  mainly  because  of  the 
lack  of  a  well  established  methodology.  The  system  design  guidelines  are  discussed 
highlighting  areas  where  basic  research  studies  shall  still  be  undertaken^  similarly 
the  system  testing  approach  is  discussed  and  a  method  of  wide  generality  is  described 
in  detail.  The  Electromagnetic  Compatibility  (EMC)  tests  commonly  devised  for  a  system 
based  upon  the  ’’black  box"  concept  shall  be  formulated  in  a  more  general  manner. 

The  overall  system  hardening  tests  which  are  now  carried  out  mainly  on  a  qualitative 
basis  shall  be  specified  cind  performed  on  a  quantitative  one. 


1.  INTRODUCTION 

In  the  design  of  present  avionic  systems  developed  according  to  the  "black  box"  functio 
nal  allocation  concept  the  electromagnetic  threat  to  avionic  equipment/subsystems  is 
specified  in  terms  of  different  disciplines  which  take  their  names  either  from  the 
source  of  the  electromagnetic  effect  such  as  NEMP  (Nuclear  Electromagnetic  Pulse), 
STATICS  (electrostatic  discharge)  or  from  the  equipment/subsystems  affected  such  as 
HERO  (Hazard  of  electromagnetic  radiation  to  ordnance),  HERF  (Hazard  of  electromagnetic 
radiation  to  fuel  ),  HERA  (Hazard  of  electromagnetic  radiation  to  avionics);  moreover 
besides  the  threat  of  the  unwanted  internal  or  external  hard  electromagnetic  environ 
ment  there  is  the  large  spectrum  of  wanted  Interferencc/disturbances  created  for  dece£ 
tion  or  Jamming  purposes:  In  this  case  one  enters  the  broad  domain  of  Electronic 
Warfare  (EW). 

By  the  replacement  of  the  functional  decomposition  approach  with  the  total  system 
approach  characterized  by  laiclear  definitive  boundaries  between  subsystems  the  previous 
concepts  based  upon  the  selective  discrimination  of  susceptibility  effects  is  obviously 
substituted  by  the  more  general  concept  of  the  electromagnetic  threat  which  will  not 
affect  a  single  black  box  but  may  interfere  with  the  correct  operations  of  the  overall 
weapon  systems. 

The  aircraft  avionic  system  has  followed  a  rapid  evolution  in  the  last  years  and  is 
expected  to  have  an  even  more  rapid  one  in  the  future.  Till  twenty  years  ago  the  avio 
nlc  system  was  an  assemblage  of  equipments  which  performed  certain  tasks  without  any 
degree  of  integration  whatsoever.  Each  equipment  was  a  collection  of  black  boxes  each 
one  connected  to  the  power  line  with  independent  output  data  presentation.  There  was 
no  electrical  signal  standardization  apart  from  very  specific  cases  such  as  the  power 
line  for  example.  Each  equipment  manufacturer  was  free  of  using  its  own  electrical 
standard  in  terms  of  signal  type  and  hardware  (cables,  connectors....).  Since  those 
years  until  now  the  avionic  system  has  become  an  assemblage  of  subsystems  related  to 
a  specific  weapon  system  function  (navigation,  weapon  delivery,  flight  control...) 
trying  to  achieve  a  higher  level  of  Integration.  Because  many  of  these  subsystems  con 
sist  of  common  elements  it  seems  reasonable  that  the  sharing  of  these  elements  among 
the  various  subsystems  could  result  in  a  more  reliable  and  efficient  system  design. 
Through  the  multifunctional  use  cf  the  system  elements  it  is  possible  to  achieve  a  more 
highly  integrated  and  cooperative  avionic  system  with  the  remarkable  advantages  of  redu 
ced  weight,  volume  and  power  consumption. 

Additional  advantages  are: 

-  using  a  single  set  of  sensors  to  satisfy  different  requirements  (a  single  wideband 
antenna  for  communication  and  navigation) 

-  sharing  processing  resources  to  cope  with  various  processing  needs 

-  Increasing  the  fault  tolerance  through  crosscheck  techniques 
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These  advantages  are  achieved  with  increased  communality  among  the  various  hardware 
parts  of  the  system.  For  example  in  a  subsystem  oriented  design  the  signal  traffic 
between  the  inertial  Instrument  and  the  navigation  computer  may  not  be  visible  beyond 
that  subsystem. 

Viceversa  in  a  system  oriented  design  with  high  level  of  integration  where  the  inertial 
instrument  is  a  sensor  shared  among  the  navigation,  fire  control  and  flight  subsystems 
it  is  essential  that  the  data  traffic  is  compliant  with  a  standard  communication  network. 
The  existing  bus  standard  is  MIL-STD-1553B;  it  has  evolved  over  the  past  ten  years  and 
represents  the  first  significant  step  towards  a  highly  integrated  system. 

It  clearly  appears  that  a  high  level  of  integration  means  a  high  levelof  standardization: 
this  fact  has  a  heavy  impact  on  the  design  and  testing  philosophy  of  the  hardware  c^mpo 
nents  of  the  system. 


2.  THE  ELECTROMAGNETIC  THREAT 

The  electromagnetic  environment  where  the  aircraft  is  required  to  operate  is  becoming 
more  and  more  crowded  with  powerful  sources  of  electromagnetic  energy  which  pose  a 
severe  system  design  requirement.  On  the  other  hand  aircraft  manufacturers  are  more 
and  more  using  composite  materials  in  the  construction  of  structures  with  the  benefit 
of  reducing  weight  and  cost  with  the  disadvantage  of  reducing  the  values  of  shielding 
efficiency  of  the  overall  aircraft.  The  aircraft  must  be  compatible  with: 

-  the  Internal  environment:  it  represents  the  electromagnetic  fields  generated  by  on 
board  intentional  and  unintentional  transmitters  which  may  cover  the  full  frequency 
spectrum  up  to  AOGHz 

-  the  external  envi ronment : It  represents  the  electromagnetic  fields  generated  by  exter 
nal  intentional  and  unintentional  sources.  High  electromagnetic  fields  are  produced 
by  broadcast  radio  transmitters  and  air  to  ground  radars  with  power  levels  up  to 
several  megawatts;  they  may  create  safety  critical  situations  in  case  of  low  level 
flight.  Intentional  transmitters  include  all  those  emitters  whose  main  purpose  con 
slsts  in  jamming  communication  and  radar  systems.  There  will  be  a  large  increase 
(both  in  power  levels  and  quantity)  of  these  types  of  emitters  Intended  to  intentio 
nally  interfere  with  electronically  dependent  systems. 

Just  recently  it  has  been  proposed  to  develop  weapons  capable  of  radiating  the  aircralt 
with  extremely  high  level  of  energy. 

These  weapons  use  generators  based  upon  new  pulsed  olasma  magnetohydrodynamic  (PPMHD) 
technology,  which  converts  the  chemical  energy  of  an  explosive  cartridge  directly  into 
pulsed  electrical  energy. 

A  condition  of  critical  external  environment  exists  during  formation  flight  when  it  Is 
possible  that  an  aircraft  flies  through  the  extremely  high  field  strengths  generated 
by  the  trasmitters  of  another  aircraft.  Lightning  and  Nuclear  Electromagnetic  Pulse 
(NEMP)  are  a  further  type  of  external  environment  which  has  also  to  be  taken  into  account. 
On  the  other  hand  integrated  circuits  are  becoming  available  with  higher  operating  speed, 
greater  gate  densities  and  lower  power  consumption:  submicron  devices  operating  at  low 
voltage  are  being  developed  with  the  consequence  that  they  will  be  more  susceptible  to  interference. 
The  year  2000  projected  RF  profile  at  integrated  circuit  pins  is  shown  in  Fig.  1  [l]  . 

These  power  levels  are  sufficient  to  create  susceptibility  effects  to  any  unprotected 
solid  state  device  over  the  frequency  range  IMHz  to  lOOGHz. 
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One  of  the  most  common  form  of  susceptibility  consists  in  the  rectification  of  the 
modulating  signal  of  the  unwanted  incident  radiation: a  pulse  modulated  out  of  band 
gnal  may  cause  the  unwanted  trigger  of  the  affected  device.  Onecan  define  the  rectify 
cation  efficiency  R  as  the  ratio  of  the  rectified  DC  voltage  at  the  device  output  to 
the  RF  power  level  incident  at  the  input  (for  an  unmodulated  signal).  In  case  of  bipolar 
transistors : 

T 

where 

K_  is  a  constant  depending  on  the  input  resistance,  capacitance  and  emitter  area 
o 

p  is  the  emitter  perimeter 
w  =  2irf  is  the  operating  frequency 


In  case  of  MOS 


devices 


Ji  = 


Kh 


is  a  constant  depending  on  the  parasitic  resistance,  the  transconductance 
Cg  is  the  InpuL,  gate  capacitance 


From  the  previous  equations  it  appears  that  the  rectification  efficiency  versus  fre 
quency  of  bipolar  transistors  is  higher  than  the  one  of  MOS  devices.  In  bipolar  trans_l 
stors  reducing  the  size  of  the  component  will  decrease  the  device  perimeter  with  the 
obvious  increment  of  R.  In  case  of  logic  circuits  Interference  effects,  while  are  not 
particularly  harmful  to  signal  prore«slna  «y«tams.  may  hav^*  effects  in 

decision  maker  systems  such  as  signal  sorters  In  EW  equipments  where  pure  logic  opera 
tions  are  carried  out.  The  susceptibility  of  logic  circuits  depends  upon  the  noise 
immunity  level  (NIL)  which  Is  defined  as  the  least  DC  noise  margin  that  exists  between 
gate  output  and  input  voltages  in  conditions  of  "0"  and  "1".  At  present  operating 
with  TTL  levels  typical  values  of  NIL'S  are  0.4V;  but  in  future  circuits  with  ECL 
technology  it  is  expected  to  operate  with  values  of  NIL'S  of  about  O.IV  with  the  obvious 
increase  probability  of  Interference. 


3.  SYSTEM  LEVEL  DESIGN 

With  the  total  system  approach  where  the  subsystems  are  provided  by  different  suppliers 
it  becomes  essential  to  establish  suitable  steuidards  as  for  example  it  has  already  been 
done  for  the  data  bus.  A  standard  to  satisfy  the  electromagnetic  threat  hardening  re 
qulrement  shall  be  established  at  the  beginning  of  a  new  project.  These  standard  guide 
lines  shall  deal  with  all  those  aspects  of  the  equipment/subsystem  design  which  are 
related  to  design  aspects  by  Ihe  Env  discipline.  They  are: 

-  grounding 

-  bonding 

-  filtering 

-  shielding 

-  connector  and  wiring 

-  electrical  interfaces 

The  guidelines  shall  not  be  a  general  collection  of  common  sense  design  rules  (as  it  ge 
nerally  happens);  but  shall  clearly  identify  the  components,  the  values  of  electrical 
parameters  which  can  guarantee  an  adequate  margin  of  safety  against  the  foreseen  elec 
tromagnetic  threat.  This  task  is  obviously  difficult  because  it  mesuns  that  more  respon 
sibility  shall  be  taken  by  the  aircraft  manufacturer  or  by  the  engineering  team  who  has 
the  design  responsibility  task. 

The  grounding  concept  and  the  electrical  interfaces  represent  keypoints  in  the  defin^ 
tion  o.  a  system.  Therefore  they  will  be  discussed  in  detail. 

The  ger?ral  lay-out  of  an  electronic/electrical  equipment  can  be  sketched  as  shown  in 
Fig.  2. 

In  this  diagram  different  types  of  grounds  are  indicated:  1  and  1’  are  the  DC  and  AC 
power  grounds  respectively,  2  is  the  signal  reference  ground  (SRG),  2'  is  the  virtual 
signal  reference  ground  of  balanced  receivers  which  may  be  isolated  from  2,  3  is  the 
equipment  structure  ground. 
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Separate  returns  for  AC  and  DC  power  grounds  are 
commonly  implemented  for  most  equipments.  The  area 
of  major  uncertainty  is  represented  by  the  manner 
of  treating  the  SRG  2:  it  may  isolated  or  connected 
to  the  equipment  structure  ground. 

In  the  Interconnection  of  the  equipments  of  a  system 
there  are  four  fundamental  ways  of  doing  it  [Fig.  3|. 

One  method  is  to  isolate  the  SRG  from  the  equipment 
case  at  the  source  and  at  the  load  providing  the  ne 
cessary  shielding  and  filtering  to  avoid  unwanted 
coupling  via  other  means  (Fig.  3a).  This  is  the 
Floating  Grouding  (7G)  system. 

It  suffers  from  many  disadvantages:  the  main  one  is 
the  static  charge  build  up  on  the  equipment  case  with 
the  possible  consequence  of  spark  hazard  to  the  inter 
nal  circuitry-  Another  grounding  scheme  is  the  Single 
Point  Grounding  (SPG)  system  where  the  SRG  of  all  the 
equipments  is  connected  to  a  Central  Signal  Point 
Ground  (Fig.  3b),  In  this  manner  there  is  no  problem 
of  common  mode  interference.  This  type  of  ground  system 
requires  a  very  large  number  of  conductors  and  there 
fore  IS  not  feasible  mainly  because  of  weight  implica 
tions.  The  main  drawbacks  of  the  SPG  grounding  scheme 
are : 

-  the  difficulty  of  implementing  the  isolation  between 
the  SRG  and  the  case  within  RF  equipments  in  conjun 
ction  with  the  increase  of  stray  capacitance  coupling; 
-  the  reduction  of  the  shielding  effectiveness  of  equipment  cases  due  to  the  grounding  wire 
penetrating  the  equipment  structure  and  therefore  violating  the  metallic  barrier.  This 
is  particularly  detrimental  for  systems  where  the  EMP  protection  is  required. 

The  third  grounding  scheme  is  the  Multi^*ie  Point  Grounding  (MPG)  system  where  the  SRG 
is  directly  connected  to  the  equipment  structure  ground  (Fig.  3c).  The  common  mode  noise 
represents  the  greatest  problem;  the  reduction  of  this  type  of  interference  is  obtained 
by  striving  for  a  zero  impedance  reference  plane.  If  a  truly  zero  impedance  ground  pla 
ne  could  be  built,  it  could  be  used  as  the  return  path  for  all  currents  (power  signal 
and  RF).  Unfortunately  the  aircraft  fuselage  structure  is  far  away  from  an  ideal  zero 
impedance  plane.  The  advantages  of  the  MPG  system  are: 

-  to  make  the  RF  equipment  design  easier  because  within  the  equipment  the  case  offers 
a  ground  plane  better  than  any  wire  and  to  avoid  complex  dec'Mjpling  systems; 

-  to  improve  the  shielding  effectiveness  of  the  equipment  because  the  metallic  barrier 
of  the  case  is  not  violated; 

-  to  eliminate  spurious  capacitive  coupling. 

The  last  grounding  scheme  is  the  Distributed  Single  Point  Grounding  (DSPG)  system  where 
the  SRG  is  connected  to  the  equipment  structure  ground  but  the  input  and  output  inter 
faces  are  differential  balanced  circuits  with  high  levels  of  Common  Mode  Rejection 
Ratio  (CMRR)  (Fig.  3d).  This  grounding  method  is  probably  the  best  one  because  it  com 
bines  the  advantes  of  SPG  and  MPG  systems.  In  order  to  have  a  high  CMRR  it  is  necessa 
ry  to  have  a  true  balanced  system  at  the  source,  at  the  load  and  along  the  conne^'t^ing 
line:  the  impedances  along  the  two  wires  of  the  transmission  path  shall  be  perfectly 
equal . 


A  unbalanced  output 
AA'  balanced  output 
B  unbalanced  input 
BB '  balanced  input 
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Fig.  4  Schematic  diagram  of  a  balanc'-d  circuit 


In  Fig.  4  the  schematic  diagram  of  a 
balanced  circuit  is  shown.  The  folio 
wing  parameters  can  be  defined 

*6 

A  7-7  -7  7  - 

- 2 — '  Zt 

It  is  possible  to  calculate  [3]  the 
transfer  functions  of  the  wanted  s^ 
gnal ,  common  mode  noise  Vn^  the 
capacitively  coupled  noise 

T  =  _!s-_  (/.K\ 


'  Rc+2c  Rc+4 

The  following  ratios  are  meaningful 


B=  J± 


'  "C, 

Zk  ^ 


The  output  voltage  of  the  differential  receiver  Is  given  by 

v,= 

where  V/  -Vi4+Vtt 

where  is  the  differential  mode  amplification  and  A  is  the  common  mode  amplifica 
tion.  In  differential  receiver,  it  is  common  practice  to  introduce  the  common  mode 
ratio  CMR  defined  as  A^ 


By  suitable  substitution  it  is  easy  to  calculate  the  output  voltage  in  presence  of 

common  mode  noise  V„ 

Na 

and  in  presence  of  the  capacitiveiy  coupled  noise  VNt» 

V,  - 

From  the  previous  equations  some  comments  are  in  order: 

-  the  CMR  of  the  differential  amplifier  alone  is  not  sufficient  to  guarantee  a  good 
rejection  ratio  if  the  overall  differential  line  Is  not  properly  balanced 

-  the  degree  of  balance  depends  on  the  line  and  on  the  transmitter  where  it  is  requ^ 
red  to  have  either  the  same  unbalance  ns  at  the  receiver  or  a  very  low  resistance 

-  the  capacitiveiy  coupled  noise  does  not  only  depend  upon  CMR  but  is  also  related 
to  Rg 
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The  balanced  transmission  line  is  a  typical  example  of  a  system  oriented  problem. 

It  is  useless  to  require  a  very  high  CMR  at  the  input  terminals  of  an  equipment  if  at 
the  same  time  adequate  precautions  are  not  taken  at  the  transmitter  end  of  the  line. 

As  it  has  been  stated  in  the  previous  paragraph  the  DSPG  system  is  mainly  based  upon 
suitable  interfaces  between  the  equipments:  the  basic  components  are  the  isolation 
amplifier  and  the  differential  amplifier.  The  Isolation  aiiiplifier  is  a  device  which 
provides  ohmic  isolation  between  the  input  and  the  output  .  It  is  particularly  suitable 
for  applications  requiring  accurate  measurement  of  low  frequency  voltage  in  the  presence 
of  high  common  mode  voltage  (thousands  of  volts). 

The  differential  amplifier  is  a  device  which  responds  only  to  the  difference  voltage 
between  inputs  and  produces  no  output  for  a  common  mode  voltage. 

Both  components  are  characterised  in  terms  of  the  Common  Mode  Rejection  Ratio  (CMRR). 
Operational  amplifiers  are  susceptible  to  RF  energy  conducted  into  either  of  the  input 
terminals . 

When  stimulated  in  this  manner  the  interference  effect  is  an  offset  voltage  at  the  par 
ticular  input  terminal  entered  by  the  RF:  this  offset  voltage  may  be  either  a  DC  level 
or  an  undeslred  low  frequency  response  due  to  demodulation  effects. 

The  magnitude  of  the  offset  voltage  depends  on  such  factors  as  the  power  level,  frequen 
cy  equivalent  RF  source  impedance  and  the  op.  amplifier  input  circuit. 

Demodulation  RFI  effects  are  greater  in  operational  amplifiers  with  bipolar  input  tran 
slstors  (741  and  LMIO)  than  they  are  in  operational  amplifiers  with  MOSFET  input  trans^ 
stors  (CA081)  and  with  JFET  input  transistors  (LF355). 

At  PF  frequencies  above  10  MHz  demodulation  RFI  effects  in  the  741  op  amplif.-'r  nre  si 
gnificantly  greater  than  in  the  LMIO  op.  amplifier.  This  is  possibly  a  result  of  the 
cutoff  frequency  of  the  npn  bipolar  input  transistors  in  the  741  op.  amplifier  being 
higher  than  the  cutoff  frequency  of  the  less  conventional  (pnp  substrate)  bipolar  input 
transistors  in  the  LMIO  op.  amplifier. 


4.  SYSTEM  LEVEL  TESTING 


Till  now  the  major  part  of  the  testing  activity  related  to  the  veri  f  < ion  of  the  equi£ 
ment  hardening  against  external  electromagnetic  interference  has  been  performed  within 
the  domain  of  the  EMC  susceptibility  tests.  These  tests  are  carried  out  according  to 
one  of  the  numerous  EMC  specifications  existing  in  the  world  which  are  all  more  or  less 
derived  from  MIL-STD-461/462A/B.  These  tests  are  divided  in  two  broad  categories:  radl^ 
ted  susceptibility  and  conducted  susceptibility.  Different  types  of  signals  (transient 
and  RF)  are  injected  by  conduction  on  power  lines  and  signal  lines  or  by  radiation  on 
the  overall  equipment.  During  the  design  of  a  new  aircraft-  tiiese  tests  are  specified 
by  the  main  contractor  to  the  equipment/subsystem  suppliers.  Even  if  they  are  accu.a*' 
in  the  definition  of  the  test  set  up  and  in  the  description  of  the  test  procedure,  they 
have  two  main  drawbacks; 

-  the  type  of  testing  implies  the  design  at  equipment  level  and  is  not  related  to  a 
system  oriented  design 

-  the  susceptibility  criteria  are  not  clearly  specified  and  in  any  case  Imply  malfunc 
tions  at  equipment  level 

The  former  point  is  particularly  misleading  because  the  system  oriented  design,  by  its 
very  nature,  operates  in  terms  of  standards  (data  bus. connector,  cable,  shielding,  signal 
format);  therefore  when  the  supplier  is  asked  to  carry  out  susceptibility  tests  it  is 
not  always  clear  whether  he  is  testing  the  quality  of  xts  equipment  or  the  quality  of 
the  standard  he  was  requested  to  use.  Additionally  t.hc  test  (especially  the  radiated 
one)  may  not  be  fully  representative  because  the  lay  out  of  the  overall  subsystem  does 
not  represent  the  actual  situation  in  terms  of  equipment  location,  cable  length  and 
routing.  In  a  highly  integrated  system  it  is  difficult  to  have  access  to  parameters 
to  be  monitored  without  affecting  the  system  under  test,  in  view  of  all  these  faci-?  i  t- 
is  essential  to  develop  test  methods  suitable  to  match  the  system  oriented  design  and 
capable  of  performing  quantitative  measurements.  Simple  qualitative  checks  intended  to 
discover  gross  interference/susceptibility  situations  on  the  basis  of  functional  interac 
tions  are  no  longer  adequate  to  clear  complex  systems;  there  is  a  well  defined  need  of 
measuring  a  quantitative  level  of  safety  before  equipment  malfunction  occurs. 

In  some  cases, because  of  its  nature  or  of  the  internal  noise, the  parameter  of  the  equi£ 
ment  under  test  changes  randomly  around  an  average  level  wirhout  the  presence  of  the 
incerference  source;  therefore  it  may  be  difficult  to  find  out  whether  the  parameter  iz 
affected  when  the  interference  source  Is  activated.  This  problem  can  be  overcome  by 


means  of  a  statistical  approach  which  can  also  be  useful  to  establish  the 
The  basic  parameters  of  a  random  variable x  which  specify  its  central 
dispersion  are  the  mean  value  ,ux  and  the  variance  defined  as 


,t  A  ^  .  A  .2 


safety  margin, 
tendency  and 
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Ttiese  estimators  are  unbiased,  efficient  and  consistent  for  the  actual  mean  value  ^ux 
and  actual  variance  (Tj,  of  a  random  variable;  however  they  result  only  In  point  estima 
tes  for  a  parameter  of  interest.  A  more  meaningful  procedure  for  estimating  parameters 
of  random  variables  involves  the  estimation  of  an  interval,  as  opposed  to  a  single  point 
value,  which  includes  the  parameter  being  estimated  with  a  certain  degree  of  uncertainty. 
Such  an  interval  can  be  determined  if  the  sampling  distribution  of  the  estimator  is  known. 
For  the  case  of  the  variance  based  upon  a  sample  variance  computed  from  N  samples 

a  confidence  interval  can  be  calculated  as 


1“ 


Qm 


is  the  Chi  -square  distribution  function 


N~± 


The  degree  of  trust  associated  with  the  confidence  statement  is  I-  ai  and  is  called  "con 
fidence  coefficient".  Furthermore  if  Is  unknown,  a  confidence  interval  can  still 

be  established  for  the  mean  value  ^ux  based  upon  the  sample  values  ^ux  and  iTx  as 
follows 

A  ^  A  a. 


A  Cx  ^ ^  A  ^  ; 

px-  ^  Mx+ 

^  Va/  ^  1/F 
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PIM  is  the  Student  Distribution  function 


The  degree  of  trust  associated  with  the  condifence  statement  is  1-0|  and  is  called  "conf^ 
dence  coefficient". 

The  practical  implementation  of  the  previous  theory  is  described  in  tne  foliwwing.  Suppo 
se  the  sensors  (R.  Altimeter,  Radar  ...)  are  connected  to  the  data  bus  through  coupler 
boxes  as  .shown  in  Ftg.S.  A  Fiber  Optic  Transmitter  is  installed  within  the  aircraft  struc 
ture  in  the  nearest  possible  position  to  Its  coupler  box.  The  fiber  optic  link  connects 
through  Che  aircraft  fuselage  the  transmitter  to  the  receiver  located  in  the  remote  pos^ 
tion  where  the  bus  Analyzer  receives  the  parameters  to  be  examined.  The  bus  analyzer  and 
the  RF  environmental  generators  are  driven  by  the  computer  which  establishes  the  sequences 
of  the  testing  procedure  which  is  divided  in  these  steps: 

a)  evaluation  of  sample  mean,  sample  variance  and  confidence  intervals  for  the  parameters 
under  test  on  the  basis  of  the  subsystem  performance  specification 

b)  evaluation  of  sample  mean,  sample  variance  and  confidence  intervals  for  the  parameters 
under  test  with  the  on  board  subsystems  in  fully  operative  conditions 

c)  activation  of  the  RF  environmental  generators  and  measurement  of  saniple  mean,  sample 
variance  and  confidence  intervals  of  the  parameters  under  test  at  different  frequencies, 
amplitude  and  modulations  of  the  RF  environmental  generators  . 

In  step  a)  one  determines  the  sample  mean  ^uo  and  its  relevant  confidence  interval  (Lo,  Uo), 
the  sample  variance  relevant  confidence  interval  CLo',  )  ■  These  represent 

the  reference  conditions.  In  step  b)  one  determines  the  sample  mean  p  and  its  relevant 
confidence  interval  sample  variance  and  its  relevant  confidence  interval 

( L ,  U^).  An  interference  margin  at  system  level  may  be  defined  as  follows. 


,,=  20Uj-^ 

5=2° 
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Fig.  5  Test  Set  up  for  system  level  test 

An  interference  situation  ( IM5y5  ^0)  In  the  fully  operative  conditions  Is  a  rlear 
symptom  of  an  integration  malfunction  to  be  solved  at  system  level.  It  15  necessary 
to  solve  the  problem  before  proceeding  to  step'^  ),  Viceversa  when  IMsys  ^  T  the 

RF  environmental  generators  can  be  activated.  In  step c  )  one  determines  the  sample 
mean  and  its  relevant  confidence  interval  U.),  the  sample  variance  ^  ^ 

N*  I 

and  its  relevant  confidence  interval  effective  interference  margin 

can  be  defined  as  follows:  (Fig.  6). 

tKs.,  =  ‘oh  ^ 

An  interferent  situation  exists  wh^n  IM  ^.^.p  >  0. 

The  evaluation  of  the  confidence  interval  is  easily  performed  for  a  fixed  level  signal 
whose  level  and  accuracy  are  known.  This  signal  may  be  represented  as  folic  j: 

a(t)  =  (C  ±  Ak 

whe  re : 

K  =  nominal  signal  level 
A  K  -  maximum  deviation 

I'he  mean  vali.ie  confidence  interval  (Lo,  !!o)  may  be  assumed  (K  -  K  A  K )  -with  a 

confidence  interval  equal  to  100^.  The  sample  mean  is  K, 

The  variance  confidence  interval  (Lo',  Uo')  may  be  assumed  (0  ,  with  a  confiden 

ce  interval  equal  to  100%,The  sample  variance  is  . 

These  measurements  can  be  performed  at  different  frequencies,  amplitudes  and  modulations 
of  the  interference  source.  It  is  also  possible  to  evaluate  a  correlation  coefficient 
the  parameter  under  test  and  the  parameter  of  the  interference  source  in  order 
to  establish  possible  relationships  which  may  be  useful  In  the  determination  of  the 
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source  of  the  problem. 

These  tests  shall  be  performed  at  rig  level  and  at  aircraft  level.  There  may  be  some 
difficulties  in  performing  radiated  tests  at  rig  level  because  the  rig  is  generally  lo 
cated  within  a  laboratory.  In  this  case  it  may  be  useful  to  perform  the  so  called  bulk 
current  injection  tests  (BCI).  The  BCI  testing  procedure  involves  current  injection  into 
the  electronic  component  under  test  by  toroidal  transformer  excitation  of  the  wiring 
harness.  The  bulk  current  injected  into  the  comporent  is  monitored  via  a  toroidal  probe 
Fig.  7.  The  advantage  of  this  test  method  consists  in  the  possibility  of  avoiding  radia 
ting  the  rig  with  the  aintenna  and  localizing  the  interference  on  a  selected  wiring  harnes 
There  are  some  disadvantages  which  are: 

-  the  need  of  a  multiple  injection  probe  system  in  case  the  subsystem  has  many  wiring 
looms  which  shall  be  interfered  at  the  same  time  in  order  to  avoid  unrealistic  up ^et 
ting  of  the  subsystem 

-  the  Injected  signal  depends  on  the  position  of  the  probe  along  the  cable  ;  it  is  neci  s 
sary  to  perform  the  test  with  the  probe  located  in  different  positions 

-  the  frequency  range  is  limited  up  to  400  MHz 

Radiated  susceptibility  tests  [SJ  can  also  be  performed  by  radiatingthe  system  under  tost 
by  means  of  tEM  cell  which  consists  of  a  section  of  rectangular  coaxial  transmission  line 
with  tapered  sections  at  both  ends.  The  taper  acts  as  a  transition  to  match  the  line  to 
a  50  Ohm  coaxial  line  at  the  two  ports  of  the  cell. 

Unfortunately  TEM  cells  have  a  limitation  on  operating  frequency  because  the  TEM  mode 
exists  only  at  low  frequency.  Moreover  since  the  polarization  of  the  field  is  fixed  the 
radiated  susceptibility  test  requires  physical  rotation  of  the  equipment  under  test. 
Another  technique  which  does  not  require  the  rotation  of  the  equipment  under  test  uses 
reverberating  enclosures  [6^  to  generate  an  average  homogeneous  and  isotropic  field 
within  a  metal  chamber.  The  homogeneous  and  Isotropic  field  is  obtained  by  rotating  a 
tuner  whose  purpose  consists  in  perturbing  the  possible  modes  existing  within  the  cavity. 
Reverberating  chamber  technique  Is  good  for  applications  at  high  frequencies;  therefore 
they  may  be  used  as  supplementary  tools  to  TEM  cells. 

Susceptibility  testo  can  be  performed  in  many  ways;  in  all  cases  the  aim  is  to  simulate 
the  environmental  conditions  where  the  equipment  under  test  shall  operate. 


Bulk  current  injection 
test  method 
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5.  CONCLUSION 

The  electromagnetic  threat  will  be  the  challenge  to  future  avionic  systems.  Therefore 
suitable  design  rules  and  testing  techniques  shall  be  established  in  order  to  built 
the  aircraft  with  an  acceptable  margin  of  safety:  the  aim  can  be  met  by  designing  and 
testing  the  aircraft  at  system  level  .  Careful  selection  of  electrical  standards  during 
the  design  phase  combined  with  the  system  level  testing  approach  represent  the  key 
points  to  be  successful  in  this  difficult  task. 
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SUMMARY 

The  inception  of  a  radar  system  is  usually  marked  by  the  building  of  a  complete 
prototype  or  pre-production  equipment.  Systems  engineers  then  have  to  prepare  for  and 
implement  a  work  programme  to  integrate  and  characterise  the  equipment  at  the  works  as 
comprehensively  as  possible  before  installation  for  flight  evaluation  in  a  suitable 
trials  aircraft. 

This  paper  sets  out  to  examine  the  process  of  commissioning,  testing  and  trialling 
of  a  complex  airborne  radar  and  attempts  to  show  how  vital  an  informed  and  methodical 
approach  is  to  achieve  success.  Indeed  neglect  or  parsimonious  treatment  of  these 
activities  can  lead  not  to  savings  but  to  chaos  or  at  best,  prolonged  iteration  with 
substantial  overspending  and  lengthening  delays. 


1.  INTRODUCTION 

The  author  has  been  engaged  in  systems  engineering  activities  in  this  field  with 
the  Radar  Division  of  THORN  EMI  Electronics  over  the  past  fifteen  years.  The  principal 
equipments  involved  have  been  prototype  and  development  models  of  the  Searchwater 
maritime  reconnaissance  (MR)  radar,  the  maritime  AEW  derivative  of  Searchwater,  the  one- 
off  installation  of  Searchwater  MR  in  a  US  Navy  Pie  and  the  current  low  cost  AEW 
Skymaster  radar. 

Searchwater  in  either  form  is  a  frequency  agile  pulse  compression  radar  featuring 
extensive  signal  processing,  and  sizeable  computer  content,  Skymaster,  which  also 
features  coherent  operation  for  pulse  doppler  AEW,  is  a  modernised  lightweight 
derivative  largely  configured  with  multi-processors, 

Searchwater  MR  is  in  squadron  service  with  the  Royal  Air  Force  in  BAe  Nimrod  MR 
MKII  aircraft.  It  should  perhaps  be  noted  that  this  variant  of  Nimrod  and  its  radar 
have  fulfilled  tneir  role  very  successfully  over  several  years  and  have  no  connection 
with  the  aborted  AEW  MKIII  project  other  than  a  common  airframe, 

Searchwater  AEW,  which  originally  evolved  as  an  emergency  adaption  for  the 
Falklands  conflict,  is  in  squadron  service  with  the  Royal  Navy  in  Westland  Sea  King 
helicopters.  It  is  also  being  supplied  to  the  Spanish  Navy  for  use  in  Sikorsky  SH3D 
helicopters, 

Skymaster  is  currently  undergoing  flight  evaluation  in  a  Pilatus  Britten-Norman 
Defender  aircraft, 

2.  PREPARATION 

It  is  important  that  the  system  engineer(s)  who  is  to  see  the  prototype  equipment 
through  to  the  conclusion  of  flight  trial  evaluation  should  be  involved  at  the  early 
stages  of  project  development  and  design.  Several  benefits  should  accrue  from  early 
involvement;  for  instance,  in  the  period  since  the  previous  major  project  of  a  similar 
kind,  the  world  of  technology  will  have  moved  on  prompting  a  quest  for  updating  even  the 
most  broadly  informed  individual’s  knowledge.  Similarly  system  techniques  known  but 
outside  the  individual's  direct  experience  may  require  time  ..or  inquiry  and 
familiarisation.  In  the  last  resort  it  is  the  practical  systems  engineer  who  will  be 
expected,  in  the  rough  and  tumble  world  of  extracting  good  performance  from  new 
equipment,  to  provide  much  of  the  inter-discipline  liaison  and  interpretation  between 
the  often  conflicting  interests  of  differing  specialists.  Nowhere  in  this  divergence 
of  interests  more  likely  to  occur  than  between  those  with  basically  hardware  orientated 
allegiance  and  those  with  software  responsibilities. 

Benefit  can  also  be  realised  at  this  stage  from  past  related  experience  in  such 
matters  as  interfacing  policy,  ergonomics  and  previous  dealings  with  equipment  operators 
in  the  armed . services . 


Nevertheless,  despite  this  it  is  important  that  the  systems  evaluation  engineer 
does  not  become  too  involved  or  tied  down  in  the  detail  engineering:  that  is  for 
others.  The  first  objective  must  be  to  come  to  terms  with  the  physical  principles  upon 
wnich  radar  performance  will  hinge.  The  engineer  should  feel  that  his  or  her  thinking 
has  got  "inside"  the  system.  It  is  not  essential  to  understand  in  detail,  circuitry, 
machine  code  or  the  more  esoteric  performance  mathematics  but  it  is  crucial  to 
appreciate  the  radar  system  and  its  arena  meaning  the  customer's  requirement,  the 
fundamental  physics  both  within  the  radar  and  in  free  space,  the  computing,  the  hardware 
and  the  system  role  within  the  total  aircraft  avionics. 

The  system  may  now  he  examined  with  more  confidence  and  dissected  into  its 
component  parts,  for  example  the  r.f.  section,  analogue  processing,  gain  control, 
thresholding,  digital  processing,  data  computation,  displays  etc.  It  is  often  helpful 
to  draw  or  redraw  functional  block  schematics  to  improve  understanding  at  this  stage. 
This  type  of  activity  assists  in  identifying  the  key  points  for  monitoring;  for  example 
detector  outputs,  gain  and  threshold  settings.  As  systems  become  more  complex,  compact 
and  interwoven  with  an  associated  dissolution  of  unit  or  "black  box"  composition 
identification  of  clear  key  interfaces  for  monitoring  becomes  more  difficult.  The 
value  and  utility  of  straightforward  monitor  or  test  points  cannot  be  overstated.  In 
cases  where  vital  data  is  neither  readily  available  nor  easily  fiecypherable , 
modifications  or  special  provision  should  be  suggested.  These  comments  apply  both  to 
the  circuitry  and  the  software  data  areas. 

At  this  same  time  vital  performance  points  and  test  objectives  can  be 
identified.  Particular  attention  should  be  paid  to  those  tests  whose  results  can  stand 
as  a  control  reference  when  the  programme  moves  on  to  the  flight  trials  stage.  Also 
likely  to  be  very  useful  for  reference  purposes  throughout  testing  and  trials  are 
reversionary  type  control  options  such  as  those  that  remove  automatic  operation  or  open 
large  feedback  loops.  Typical  examples  are  manual  rather  than  automatic  receiver  gain 
control  and  manual  rather  than  CFAR  setting  of  thresholds.  It  may  be  prudent  to 
introduce  options  of  this  tvpe  even  where  no  long  term  operational  requirement  exists. 

Where  reviewing  the  system  key  performance  features  those  associated  with 
navigation  inputs  to  the  radar  merit  close  scrutiny.  Motion  compensation  errors  from 
aircraft  navigation  sensors  have  been  known  to  severely  impair  overall  radar  performance 
once  airborne.  Hue  to  the  different  disciplines  involved,  it  has  not  been  unknown  for 
the  Inertial  Navigation  System  (INS)  contractor  to  have  a  genuine  but  very  different 
interpretation  of  a  key  specification  clause  to  that  r-f  the  radar  designers, 

A  system  test  rig  or  area  has  to  be  prepared  in  readiness  for  the  arrival  of  the 
main  equipment,  Sasic  requi re-i*.  “ts  include  ample  space  for  an  accessible  layout, 
power,  temperature  conditioning  together  with  support  infrastructure  such  as  cable 
gantries  and  benches.  In  addition  commercial  items  such  as  D.C.  power  supplies, 
keyboards,  printers  and  capital  test  equipment  have  to  be  ordered  or  obtained. 

Staffing  the  whole  operation  through  to  flight  trialMng  has  also  to  be 
considered.  The  author's  experience  is  that  progress  is  best  sustained  by  a  small 
nucleus  of  full  time  staff  with  support  from  project  specialists  as  and  when 
appropriate.  The  value  of  a  good  artisan,  particularly  a  prototype  wireman,  to 
implement  permissible  modifications  and  construct  special  to  type  test  apparatus  ought 
not  to  be  overlooked.  It  is  sound  policy  to  introduce  trials  or  field  engineers  to  the 
system  concept  at  this  stage  prior  to  participation  in  the  later  system  characterisation 
measurements. 

3.  INTRGRATTON  AND  COMMISSIONING 


A  schedule  for  these  activities  should  be  drawn  up  to  shown  in  some  detail  the 
sequence,  nature,  effort  and  anticipated  time  for  each  step.  The  procedure  outlined 
may  be  smartly,  even  sharply  timed  but  it  should  always  be  methodical  and  include  time 
for  regular  written  reports.  The  schedule  may  well  be  widely  agreed  at  the  outset  but 
too  often  projects  run  late  due  to  delays  for  example,  in  design  or  card  manufacture 
increasing  pressure  on  the  system  programme.  System  integration,  characterisat ion  and 
trialling  being  the  last  in  line  of  all  development  activities  there  is  a  very  real 
danger  of  expedient  policies  being  suggested.  The  argument  may  even  he  advanced  that 
the  system  merely  requires  assembly,  switching  on  and  all  will  be  fine.  rjnf ortunate 1 y 

with  complex  equipment  this  is  never  so,  for  umpteen  sundry  reasons.  Total 
acquiescence  to  this  type  of  policy  therefore  is  very  likely  to  result  in 
disorganisation  and  further  delay.  In  the  event  therefore  schedules  may  have  to  be 
reviewed  carefully  hut  not  severely  compromised. 


Built-In-Test-Equipment  (BITE),  once  itself  commissioned,  is  a  useful  aid  to  system 
integration  and  problem  diagnosis  but  the  rig  team  ought  also  he  watchful  for  other  ways 
in  which  the  radar  can  in  effect  check  itself,  without  resort  to  expensive  test 
equipment.  For  instance,  where  alternative  modes  or  facilities  exist  each  may  be 

cross-checked  against  the  other.  it  is  also  helpful  to  assess  and  establish  the  system 
quiescent  conditions  in  noise  limited  conditions.  These  include  receiver  gain  demand, 
mean  detector  output,  threshold  setting  and  overall  false  alarm  rates.  A  confident 
knowledge  of  these  simple  parameters  allows  a  rapid  daily  or  pre-measurement  check  to  be 
made;  for  random  component  failure  may  occur  at  any  time  to  confuse  the  situation  and 
perhaps  invalidate  lengthy  measurement  results. 


Self  test,  formal  or  improvised,  is  of  course  never  enough  to  chart  performance 
sufficiently  to  ensure  a  confident  transfer  of  the  equipment  to  an  aircraft. 

Simulators,  sophisticated  and  simple,  are  also  required  to  provide  amongst  other  things 
interface  checks,  synthetic  target  generation  and  synthetic  aircraft  motion  (linear  and 
manoeuvre) . 

The  rig  will  also  require  appropriate  video  and  data  recording  together  with 
corresponding  replay  facilities.  Some  of  this  will  be  common  with  the  planned  aircraft 
instrumentation.  It  may  be  appropriate  to  modify  the  rig  signal  processing  to  absorb 
and  reprocess  in-flight  video  to  be  recorded  later  from  a  tap  at  the  corresponding  point 
in  the  signal  chain,  "Real"  data  of  this  form,  even  though  inherently  frozen  beyond 
adjustment  and  mildly  distored  by  recording  imperfections,  can  be  invaluable  in  the 
refinement  of  some  processing  techniques  particularly  autotracking.  Recorded  data  both 
taken  in  flight  or  from  a  rig  may  also  often  provide  the  means  of  capture  of  fast  or 
transient  events  for  subsequent  replay  and  analysis  in  a  slower  time  frame. 

The  commissioning  or  integration  process  itself  almost  always  progresses  by  a 
process  of  attrition.  The  common  belief  is  that  once  the  current  problem  or  barrier  to 
progress  is  removed  everything  will  fall  into  place  but,  in  the  event,  removal  cf  the 
first  problem  reveals  the  next  and  so  on,  truly  a  situation  analogous  to  a  set  of 
"Russian  Dolls". 

Persistence  and  tenacity  are  of  course  generally  rewarded  and  the  system 
credibility  should  rapidly  improve.  At  this  stage,  if  not  before,  some  of  the  firmware 
and  software  will  have  been  exercised,  improved  and  refined  on  the  rig.  This  is  fine 
but  the  software  people  will  have  discovered  the  benefits  of  rig  system  access  to  test 
new  ideas  and  directly  resolve  their  problems  on  the  radar  itself.  This  factor  has  to 
be  monitored  closely  otherwise  excessive  system  rig  time  may  be  absorbed  in  esoteric 
software  development  tasks.  Uncontrolled  or  over  frequent  changes  to  software,  however 
well  intentioned,  may  also  undermine  general  system  performance  consistency.  For 
example  it  has  been  known  for  a  set  of  control  settings  to  be  chosen  for  a  measurement 
programme,  midway  through  which  an  apparently  innocent  change  of  software  is  introduced 
bringing  about  a  subtle  system  reinterpretation  of  one  of  the  control  settings  with 
consequent  confusion  and  time  wastage. 

4,  CHARACTERISATION 

System  characterisation  activities  begin  to  infuse  into  the  workload  at  about  this 
stage.  Emphasis  changes  from  the  somewhat  mechanistic  and  quantitative  commissioning 
or  integration  tasks  to  the  more  quantitative  nature  of  characterisation.  The  purpose 
here  is  to  provide  calibration  and  reference  data  as  far  as  is  sensibly  attainable  in 
the  laboratory.  The  results  obtained  have  to  be  compared  with  theoretical  or  modelled 
performance  and  should  be  retained  for  reference  purposes  in  subsequent  flight  testing. 

Comparisons  with  anticipated  performance  may  well  present  the  systems  engineers 
with  some  shortfall  to  explain.  Hopefully  this  is  not  serious  but  some  reassessmenl  of 
tolerances,  error  budgets  and  losses,  both  r.f,  and  processing,  is  all  too  frequently 
required  before  all  the  "missing  dB's"  can  be  largely  accounted  for. 

At  this  stage  the  prototype  system  should  approach  a  state  of  readiness  for  flight 
testing.  There  may  be  a  little  tidying  up  to  be  done  and  where  sponsorship  by  a 
government  agency  is  involved  some  form  of  acceptance  test  to  be  arranged  and 
implemented.  A  stage  report  is  usually  advisable  at  this  time, 

5.  FLIGHT  TRIALS 

Preparation  and  planning  for  flight  trials  will,  by  this  point,  have  progressed  to 
an  advanced  stage.  Flight  trialling  is  a  very  different  situation  to  laboratory  system 
testing.  The  latter,  despite  all  the  problems  encountered  on  the  way,  offered  a 
relatively  clinical  environment,  time  to  think  and,  most  importantly,  opportunity  to 
repeat  an  observation  under  virtually  identical  conditions.  In  the  aircraft  none  of 
these  luxuries  can  be  relied  upon,  even  in  the  most  well  appointed  four  engined 
transport.  The  equipment  Itself  is  less  accessible  and  accurately  controllable 
conditions  are  unattainable.  Range  and  bearing  geometry  to  a  chosen  contact,  as  a 
simple  example,  are  continuously  changing:  no  one  can  stop  the  aircraft  to  check  a 
measurement. 

In  response  to  this  situation  one  school  of  thought  advocates  extensive  video 
recording  and  other  data  collection  taken  robot  fashion  in  pre-planned  rigid  trials 
without  scope  for  improvisation.  Heavy  reliance  is  then  placed  on  post-flight 
analysis.  This  approach  has  merit  particularly  in  any  earlier  study  trials  but  in 
equipment  design  proving  trials  there  is  no  substitute  for  direct  observer  deduction 
with  a  degree  of  on  the  spot  improvisation  to  obtain  conclusive  evidence. 

Where  data  collection  and  ground  analysis  methods  are  resorted  to,  control  has  to 
be  exercised  to  both  avoid  overwhelming  the  analysts  with  excess  data  and  to  validate 
the  relevance  and  quality  of  all  recorded  data  before  the  termination  of  flying.  An 
incomplete  set  of  in-flight  results  found  after  grounding  the  equipment  may  prove  a  very 
expensive  omission. 
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The  foregoing  case  for  system  engineers  participating  as  flight  observers  implies  a 
further  set  of  qualities  in  staff  selection.  This  goes  further  than  merely  obtaining 
medical  certification  and  possessing  a  capacity  for  quick  thinking.  This  same  fast 
thought  processing  will  often  have  to  take  place  in  an  adverse  environment.  Critical 

decisions  and  technical  deduction  may  %#ell  be  required  several  hours  say  into  an  all 
night  trial  carried  out  at  low  level  in  conditions  which  have  buffeted  the  aircraft  and 
its  occupants  without  relief.  Add  to  this  the  nausea-inducing  odours  which  pervade 
aircraft  from  their  hydraulic  and  lubrication  systems,  not  to  mention  the  indelicate 
aroma  of  hot  soup  and  foodstuffs  emanating  from  the  galley  (surely  intended,  on  such 
occasions,  for  only  the  most  masochistic  of  the  full  time  professionals)  and  the  value 
of  a  strong  constitution  is  clear. 

The  observer's  ordeal  on  a  rough  trip  may  not  end  on  landing  for,  apart  from 
possible  post-flight  checks  and  calibration,  there  will,  if  the  trial  is  staged  from  a 
military  base,  be  other  commitments.  First  exposure  of  a  new  equipment  to  the  relevant 
military  is  bound  to  provoke  their  intense  curiosity.  The  trials  crew  are  typically 
questioned  at  length,  often,  truth  to  tell,  over  drinks  at  a  service  barl  This 
liaison,  whilst  virtually  specifying  a  social  dimension  to  the  job  is  not  without  worth 
to  the  project  team  for  it  provides  valuable  insight  into  the  future  operators'  attitude 
and  expectations.  Later  this  type  of  experience  can  be  put  to  nood  use  in  devising 
training  schemes  for  the  service  user.  It  also  helps  to  establish  an  alternative 
informal  liaison  channel  through  which  later  problems  or  minor  improvements, 
particularly  to  software,  may  be  discussed. 

The  first  tangible  hurdle  at  the  flight  trials  stage  is  the  actual  installation. 
This  may  have  been  preceded  by  "mock  up"  checks,  involving  cable  and  waveguide  runs 
together  with  weight  and  electrical  dummy  loading  in  which  some  preliminary  flying  could 
have  taken  place.  In  this,  excellent  support  from  full  time  field  engineering  is 
greatly  appreciated.  Ideally  key  members  from  the  field  team  will  have  been  present  at 

the  works  during  the  characterisation  stage  to  familiarise  themselves  with  the  new 
radar.  This  should  materially  improve  the  prospects  of  an  elegant  installation  with 
minimal  delay. 

The  value  of  good  field  engineering  support,  embodying  knowledge  and  experience 
peculiar  to  their  kind  and  not  easily  unearthed  from  textbooks,  is  high.  The  systems 
engineers  may  know  the  radar  inside  out  but  without  guidance  through  the  formalities  and 
everyday  jargon  of  the  flying  industry,  in  or  out  of  the  air,  they  would  soon  flounder 
in  confusion. 

Following  installation  some  ground  running  is  customary.  Adequate  ground  supplies 
have  to  be  arranged  if  use  of  main  engines  or  an  onboard  generator  is  to  be  avoided. 

This  ground  running  may  be  the  first  opportunity  for  radiation  checks  on  a  complete 
system.  In  such  cases,  with  proper  safety  measures  taken,  a  convenient  object  on  or 
beyond  the  immediate  horizon  such  as  a  spire  or  a  water  tower  may  be  enlisted  to  confirm 
essential  radar  loop  characteristics  such  as  pulse  compression  or  coherence. 

Other  checks  verifying  both  the  integrity  of  the  equipment  and  the  retention  of 
characteristics  following  installation  are  performed  in  this  ground  phase. 

Tests  also  have  to  be  run  to  demonstrate  that  the  radar  is  essentially  hazard  free 
both  to  the  aircraft,  Its  equipment  and  its  occupants. 

The  first  flights  are  also  concerned  with  safety?  followed  soon,  if  all  is  well, 
with  what  are  known  as  "shake  down"  activities.  If  the  radar  is  some  form  of 
surveillance  type  with  an  approximation  to  real  time  display,  much  may  be  gleaned  by 
informed  observation.  System  areas  requiring  initial  in-flight  verification  before 
pressing  on  with  formal  trialling  include  antenna  stabilisation,  host  aircraft  motion 
compensation,  any  serious  BITE  indications,  display  uniformity  {i.e,  background  levels 
and  false  alarm  rates)  together  with  some  qualitative  indication  of  the  detectability  of 
valid  targets  of  opportunity  e.g.  aircraft,  ships  or  road  vehicles.  It  should  also  be 
possible  to  gauge  the  approximate  extent  of  clutter  penetration  and  compare  with 
expectation  for  the  prevailing  conditions.  This  period  may  reveal  the  need  for  limited 
modification  and  redesign  but  in  general  it  should  be  seen  as  a  learning  phase. 

All  round  confidence  will  evolve  to  the  stage  where  formal  trialling  with 
cooperative  targets  commences.  Again  it  is  important  initially  to  curb  over  ambitious 
aspirations  and  to  keep  situations  simple.  The  disposition  geometry  should  be 
straightforward,  target  manoeuvres  limited  and  at  each  progression  only  a  single  aspect 
of  either  target  or  radar  changed.  At  all  times  the  situation  should  be  constrained  to 
the  minimum  number  of  variables.  in  this  way  the  results  obtained  will  be  explicable 
and  most  probably  pleasing  and  satisfactory.  It  is  also  at  this  stage  that  the  real 
value  of  the  laboratory  characterisation  is  apparent.  The  earlier  laboratory  and 
ground  results  provide  the  foundation  or  reference  agains*-  which  airborne  performance 
may  be  both  judged  and  understood.  A  trial  organised  in  this  way  from  such  a  base  will 
be  less  subject  to  crisis,  under  better  control  and  better  able  to  supply  answers  to 
criticism,  A  major  hazard  which  is  avoided  by  not  embarking  ill-prepared  into  complex 
radar  trials  is  that  not  only  are  the  problems  less  likely  to  be  difficult  to  unravel 
but  the  resultant  climate  tends  not  to  induce  flawed  theories  and  myths  which  can 
themselves  become  further  obstacles  to  understanding  and  progress. 


The  tendency  is  for  the  truth  of  these  reiwarks  to  intensify  as  the  tri&l  progresses 
from  detectability  aspects  into  the  information  extraction  processes  such  as 
autotracking.  Throughout  a  disciplined  and  documented  record  of  the  trials  should  be 
maintained.  A  minor  problem  to  flight  observers  in  this  respect  is  the  means  of  noting 
their  own  thoughts  and  jottings  during  flight.  Handwritten  notes  in  a  standard 
engineers  notebook  which  probably  has  to  be  hand  held,  are  certainly  unsuitable  and  an 
impediment  to  concentrated  observation.  Some  form  of  shorthand,  improvised  perhaps#  in 
a  flip-over  notepad  is  better  while  a  pocket  audio  recorder  is  perhaps  best.  In  a 
similar  vein  the  systems  observer  requires  an  ability  to  retrieve  general  system 
information  quickly  if  he  is  to  react  fast  enough  to  an  unexpected  situation.  A  simple 
example  could  be  the  selection  of  an  altitude  adjustment  to  sight  the  surface  horizon  at 
an  amended  range.  Backing  up  limited  human  memory  could  call  for  a  library  of 
specifications,  computer  print  outs  and  other  reference  data  to  be  carried  on  board,  A 
simple  pocket  notebook  can  be  packed  with  an  amazing  and  evolving  amount  of  general 
unclassified  information  to  provide  an  excellent  and  compact  aide-memoire. 

As  with  the  characterisation  phase  the  trial*s  end  and  major  i nt p»'med i ate  stages 
should  be  marked  with  the  issue  of  formal  findings  reports. 

6.  CONCLUSION 

This  paper  has  attempted  to  identify  a  general  approach  or  philosophy  to  the 
commissioning  and  performance  evaluation  of  a  new  airborne  radar.  The  approach  sets 
out  to  achieve  an  integral  programme  from  building  up  the  system  through  to  the 
completion  of  flight  trials.  A  methodical  anu  informed  process  has  been  advocated 
which  it  is  hoped  gives  an  insight  into  the  importance  of  progressing  such  a  major 
activity  from  a  firm  and  growing  foundation.  In  this  way  good  technical  control  can  be 
maintained  and  the  answers  to  criticism  or  unexpected  system  behaviour  may  be  provided 
with  authority. 

It  is  essential  to  the  approach  that  higher  management  understands  and  supports 
it.  The  systems  engineer  may  well  be  subject  to  overtures  to  cut  schedules  or  to  think 
more  positively  in  the  hope  that  it  will  all  work  first  time.  The  sense  of  urgency 
should  he  acknowledged  but  the  basic  message  must  be  got  through  and  retained. 

Otherwise  the  probability  of  debacle  and  associated  escalating  costs  to  the  project  and 
its  reputation  can  be  very  high. 
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This  paper  attempts  to  predict  some  future  trends  in  microelectronics.  The  paper  focuses  on  CMOS 
integrated  circuit  technology.  CMOS  is  presently  Che  leading  Integrated  circuit  technology,  and  all 
trends  show  that  it  vill  contin'ie  to  dominate  the  Integrated  circuit  market  in  the  future. 

I  exasilne  the  processing  of  vhat  I  feel  will  be  the  two  leading  CMOS  technologies  of  the  future, 
twin  tub, and  silicon  on  insulator  (SOI).  These  two  technologies  have  the  capability  of  giving  maximum 
CMOS  device  performance.  With  device  geometries  shrinking  the  problems  associated  with  scaling  are 
Introduced,  and  some  possible  solutions  are  examined.  The  paper  is  concluded  with  a  brief  description 
of  some  fundamental  limits  in  integrated  circuit  technology. 


This  paper  will  attempt  to  provide  a  brief  overview  of  semiconductor  processing  trends  and 
semiconductor  material  trends.  To  start  a  look  at  where  we  have  been  is  a  good  idea.  Starting  fifteen 
years  ago  bipolar  transistors  were  widely  being  used  and  MOS  devices  were  starting  to  be  widely  used  in 
hand  held  calculators  and  products  that  required  small  power  consumption.  At  the  time  a  large  device  had 
8000  transistors.  Ueaory  devices  were  Just  emerging  as  well  as  four  bit  microprocessors.  In  the  1960'8 
the  Integrated  circuit  market  was  mostly  comprised  of  bipolar  transistors  for  both  digital  and  analog 
applications.  In  the  mid  1970' s  digital  HOS  overtook  bipolar  technology  in  the  digital  arena  and  with 
decreasing  geometries  MOSFET'S  are  also  challenging  in  the  linear  arena.  (Ref  l) 

We  have  come  a  long  way  in  the  last  fifteen  years.  We  now  have  chips  with  hundreds  of  thousands  of 
translstorsi  device  geometries  have  shrunk  below  the  one  micron  range.  MOS  devices  operate  in  the  100  MHZ 
range  when  not  to  many  years  ago  they  only  operated  in  the  several  hundred  KHZ  range.  Bipolar  technologies 
are  approaching  the  GHZ  range.  GaAS  is  being  used  for  very  high  speed  applications  l.e.  a  digital  flip 
flop  has  had  reported  speeds  of  18  GHZ.  Technologies  are  being  mixed,  bipolar  and  C1408  on  the  same  chip. 
People  are  looking  at  using  GaAS  on  silicon  to  get  the  advantages  of  both  technologies.  Silicon  on 
Insulator  (SOI)  seems  to  be  a  promising  technology.  ASIC  (application  specific  Integrated  circuits) 
technology  has  become  common  and  device  geometries  in  the  one  to  three  micron  range  have  become  quite 
common.  Gate  arrays  with  80000  gates  or  more  have  become  available  on  the  commercial  market.  These  events 
have  led  to  a  different  design  methodology  as  the  systems  become  much  more  complex  and  the  density  of 
the  chips  increases.  System  designers  and  IC  designers  have  become  more  dependent  on  computer  tools  to 
aide  them  in  their  work. 

In  this  paper  I  am  going  to  concentrate  on  CMOS  technology.  All  trends  point  to  the  continued  increase 
of  the  use  of  CMOS  in  the  future.  I  will  first  give  a  quick  overview  of  VLSI  processing  trends  and  a  little 
insight  to  vhat  the  processing  of  the  iuture  might  be.  I  vill  then  talk  about  parasltlcs  in  CMOS  devices 
since  these  are  limiting  factors  in  device  performance.  Then  I  will  talk  about  two  different  CMOS 
processing  technologies,  (l)  twin  tub  and  (2)  silicon  on  insulator  and  show  how  different  processing 
techniques  can  help  eliminate  many  of  the  parasitic  problems.  I  will  then  examine  first  order  scaling 
and  show  why  first  order  scaling  doesn't  work  in  the  sub  micron  range,  I  vill  finish  by  taking  a  brief 
look  at  some  of  the  fundamental  limits  of  device  physics.  These  limits  will  include  quantum  mechanical 
limits  and  thermal  limits. 

Processing  Trends 

In  this  section  I  will  give  a  brief  overview  of  the  following  subjects, 

1)  epitaxy 

2)  diffusion 

3)  ion  implantation 

k]  lithography 

8)  etching 

6)  multi  level  metal 

This  section  is  not  necessary  reading  for  the  continuity  of  the  paper  but  can  serve  more  for  a  reference 
or  as  a  simple  review  for  people  not  familiar  with  microelectronics  processing.  A  good  starting  point  is 
epitaxy.  Most  epitaxy  is  done  by  chemical  vapor  deposition.  As  dimensions  get  smaller,  molecular  beam 
epitaxy  vill  become  more  prevalent.  The  advantage  of  MBE  Is  that  it  is  a  low  temperature  process  which 
minimizes  outdlffusion  and  autodoping.  MBE  allows  precise  control  of  doping,  and  more  importantly 
complicated  doping  profiles  can  be  done  with  MBE.  Epitaxy  can  also  be  Important  for  silicon  on  insulator 
MOS  technology  which  vill  greatly  Increase  speeds  because  of  reduced  parasities.  Because  of  the  many 
problems  associated  with  this  a  non  epitaxial  approach  for  providing  single  crystal  silicon  is  being 
used.  There  are  two  common  non  epitaxial  approaches,  (1)  deposit  polysllicon  on  an  amophous  substrate, 
and  recrystallze  the  silicon  by  a  thermal  means,  (2)  do  a  deep  ion  implant  of  oxygen  which  forms  a  burled 
layer  of  silicon  dioxide  and  then  recrystallze  the  silicon  on  the  surface. 'Both  of  these  methods  have 
problems  minimizing  the  defect  density  of  the  silicon. 

The  next  subject  that  I  want  to  discuss  briefly  is  diffusion.  Rot  much  nssds  to  be  said  about 
diffusion  other  than  Junction  depths  of  1000  angstroms  can  bs  realizsd  but  profile  maasurement  techniques 
commonly  used  are  only  good  for  depths  of  about  one  micron.  However  the  secondary  ion  mass  spectroscope 
allows  measurement  of  shallow  Junction  profiles  and  is  a  powerful  analysis  tool. 

The  next  topic  is  ion  implantation  and  is  very  important  to  VLSI  technology.  Ion  implantation  is 
the  bombardswnt  of  a  target  with  energizled  ionized  atoM.  This  causes  the  atoms  to  be  implanted  below 
the  surface.  Typical  energies  are.  from  3  to  800  KeV  resulting  in  the  atom  being  implanted  from  about 
100  angstroms  to  10000  angstroms  below  the  surface.  A  big  advantage  of  ion  implantation  is  the  number 
of  dopant  atoms  can  be  very  well  controlled  and  the  depth  profile  can  be  well  controlled.  Ion  implantation 
is  used  in  all  or  practically  all  doping  steps  in  present  VLSI  technology.  In  the  future  very  shallow 
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Junction  depths  will  be  ceen  In  MOS  technology,  100  angstroms  or  less.  An  Interesting  note  Is  that 
since  ion  implantation  is  a  kinetic  process  the  eventual  shallowest  Junctions  are  probably  obtainable 
from  thermal  diffusion  and  not  ion  implantation  (Ref  2).  Although  it  will  be  a  long  time  before  ion 
implantation  is  not  the  practical  choice. 

The  next  section  is  on  lithography.  This  Is  the  defining  process  as  far  as  future  IC  production  goes. 

The  prevalent  lithographic  process  now  in  use  is  optical  lithography.  The  reason  for  this  is  the  high 
throughput  of  optical  lithography.  Good  registration  and  the  resolution  is  adequate  for  most  present  day 
commercial  processes.  Diffraction  is  the  limiting  factor  for  optical  lithography  and  until  recently  one 
micron  was  believed  to  be  the  lover  lisilt  for  optical  lithography.  But  with  the  advent  of  trl  level 
photoresists  and  contrast  enhancement  material  0.$  micron  resolution  has  been  achieved.  Other  ways  to 
improve  optical  lithography  is  to  go  to  ssuiller  and  ssialler  wavelengths.  Deep  UV  and  xray  lithography 
are  presently  being  examined.  Xray  lithography  is  promising  because  of  the  short  wavelengths  (  around 
ten  angstroms)  but  masking  is  a  very  dlffucult  problem  that  needs  to  be  solved  before  xray  lithography 
becomes  practical.  There  is  a  real  limit  to  optical  lithography  and  non  optical  methods  are  becoming 
more  common.  On  the  non  optical  front  electron  beam  lithography  is  very  popular.  In  electron  beam 
11‘hography  an  electron  beam  directly  writes  on  the  mask  or  the  substrate.  Therefore  electron  beam 
lithography  gives  better  resolution  than  optical  lithography.  The  limiting  factor  for  electron  beam 
lithography  is  the  backscatter  of  electrons  off  the  substrate,  this  is  called  the  proximity  effect. 

One  step  further  is  ion  beam  lithography  which  will  reduce  backscatter  and  thus  give  better  resolution, 

Monte  Carlo  simulation  shows  ion  beam  lithography  to  have  negligible  backscatter  and  therefore  shows  no 
proximity  effect. 

The  next  subject  is  etching.  I  won't  even  discuss  wet  etching  because  it  is  not  practical  for  VLSI 
technology  where  the  dimensions  are  so  ssiall  that  an  Isotropic  etch  cannot  be  tolerated.  Dry  etching 
techniques  are  the  predominant  etching  tools  for  the  VLSI  and  ULSI  era.  Among  these  reactive  ion  etching 
is  very  good  because  it  allows  an  anisotropic  and  a  preferential  etch.  I  also  want  to  briefly  touch  on 
multilayer  metal.  As  device  geometries  continue  to  shrink  device  Interconnect  becoaws  a  real  problem. 

A  large  amount  of  useable  silicon  can  be  consumed  Just  by  device  interconnect.  The  way  to  get  around  this 
is  multilevel  metal.  By  going  to  two,  three,  four,  and  even  five  layers  of  Interconnect  the  density  can 
be  greatly  Increased,  But  going  to  multilevel  metal  is  not  a  trivial  problem.  Two  layer  metal  is  now  common 
and  three  and  four  layer  metal  la  being  developed  but  there  have  been  real  yield  problems  associated  with 
these.  You  need  good  Interlevel  dielectrics  that  are  planariced,  free  from  pinholes  and  have  a  low  dielectric 
constant. 

CK02  ParaultlcB 

I  will  now  discuss  parasitic  capacitances  and  resistances  and  latch  up  of  CMOS  devices.  In  order 
to  maximize  the  performance  of  the  devices  these  parasitica  must  be  greatly  reduced.  An  understanding 
of  the  parasitica  associated  with  these  devices  will  help  us  understand  what  will  have  to  se  done  in  the 
future  to  maximize  device  perforsiance.  Parasitic  capacitances  play  a  major  factor  in  inhibiting  the  device 
speed  of  MOS  circuits  so  it  is  paramount  to  minimize  this  capacitance.  There  are  source  substrate  capacit¬ 
ance,  drain  substrate  capacitance,  gate  substrate,  gate  drain  and  gate  source  capacitance.  There  are  many 
factors  that  affect  the  capacitance  but  for  our  purpose  all  we  need  to  know  is  that  we  must  minimize  it 
to  maximize  device  performance.  Also  of  great  concern  is  Interconnect  capacitance  and  resistance  thus 
leading  to  RC  delays.  As  circuit  density  Increases  and  line  widths  decrease  and  wiring  resistance  and 
associated  delays  become  very  critical.  This  leads  us  to  multilayer  metal  schemes. 

Two  other  effects  that  I  want  to  mention  are  the  body  effect  and  latch  up.  In  the  region  where  the 
gate  source  voltage  is  greater  than  threshold  voltage  then  the  substrate  bias  is  the  voltage  of  the 
source  minus  the  substrate  voltage.  As  the  substrate  bias  increases  the  associated  channel  substrate 
depletion  layer  Increases.  This  traps  more  charge  in  this  layer  causing  the  channel  charge  to  decrease. 

Go  this  increases  the  threshold  voltage  which  lessens  current  flow  and  thus  makes  circuits  slower.  This 
is  culled  the  body  effect  for  obvious  reasons.  Latch  up  is  caused  when  enough  current  is  injected  into 
the  substrate  to  turn  on  two  bipolar  transistors  an  NPH  and  a  PNP  that  are  fonsed  by  the  different  dopings. 
Thus  depending  on  substrate  reslstence  in  the  parasitic  path  the  current  draw  can  be  large  and  cause 
circuit  failure.  Both  these  effects  can  be  minimized  or  eliminated  with  different  processing  techniques 
i.e.  silicon  on  Insulator, 

CMOG  Technology 

As  previously  pointed  out,  CMOS  technology  seems  to  be  the  technology  of  the  future.  Therefore,  in 
this  section  I  am  going  to  talk  about  the  process  integration  of  CMOS  devices.  I  am  not  going  to  discuss 
single  well  technology  since  I  am  Interested  in  optimizing  both  n  channel  and  p  channel  devices.  There¬ 
fore  the  two  technologies  that  I  will  discuss  are  twin  tub  CMOS  and  SOI  processes. 

TWIN  TUB 

Twin  tub  allows  the  optimization  of  both  p  channel  and  n  channel  transistors.  The  general  processing 
sequence  for  the  twin  tub  process  is  to  start  with  a  ne  or  p*'  substrate.  Put  a  lightly  doped  epitaxial 
layer  on  top  of  this  to  help  prevent  latch  up.  Form  your  n  and  p  wells.  Then  a  oxide  is  put  down  and 
patterened  for  the  gates.  A  thin  oxide  la  grown  for  the  gates.  Polysilicon  is  then  deposited  over  the 
wafer  and  etched  to  form  the  gates.  Then  Boron  and  Phosphorous  ImplantiAlons  font  the  n  and  p  regions 
for  the  source  and  drain  regions.  The  circuit  is  then  passivated  and  contact  cuts  are  made  to  the  silicon 
and  metal  is  deposited.  The  metal  is  etched  end  another  dielectric  la  deposited,  vlas  are  etched  and 
metal  is  again  deposited.  This  multilayer  metal  could  encompass  two,  three,  cr  even  four  layers.  At  a 
final  note,  blocks  of  transistors  are  separated  by  deep  trench  isolation.  By  deep  trench  I  mean  trenches 
deeper  than  the  well  diffusions.  The  tubs  within  these  regions  abutt  so  there  needs  to  be  a  Vdd  and  Vss 
contact  to  the  n  and  p  wulls. 

SILICON  OH  1H8UUT0R 

BOl  has  the  potential  for  being  the  fastest  of  the  MOS  devices.  It  is  also  the  most  dlffucult  to 
process  and  accordingly  the  most  expensive.  But  changes  in  processing  capability  will  eventually  change 
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this.  The  processlfm  goes  as  follows.  Put  a  thin  layer  of  silicon  on  an  Insulator.  This  can  be  sapphire 
or  spinel  or  It  can  be  an  asnrphoua  dielectric  using  new  non  epitaxial  swans.  These  non  epitaxial  sieans 
look  very  prosilslng  for  the  future.  Then  etch  the  silicon  to  fora  Islands.  The  etch  mst  be  anisotropic 
since  the  separation  of  the  Islands  will  be  aueh  less  than  the  thickness  of  the  islands.  Hext  the  p 

Islands  are  nasked  with  photoresist  and  a  phosphorous  laplant  foras  the  n  Islands.  The  n  Islands  are  then 

Basked  with  photoresist  and  a  boron  liq)lant  foras  the  p  islands,  text  a  thin  gate  oxlac  Is  grown  over  the 

structures  and  polyslllcon  is  deposited  and  etched  to  fora  the  gates.  Hext  the  sources  and  drains  are 

formed  by  selective  aasklng  of  Islands  and  phosphorous  and  boron  laplants  respectively  form  the  sources 
and  drains  of  the  p  type  and  n  type  devices.  Hext  a  dielectric  is  deposited  over  the  whole  device  and 
contacts  are  cut  and  metal  Is  deposited.  There  will  be  multiple  layers  of  aetal  In  order  to  allow  full 
utilization  of  the  increased  gate  density.  With  the  high  density,  planarization  techniques  become  very 
Important  In  making  good  step  coverage  possible. 

Silicon  on  Insulator  la  very  attractive  because  of  the  following  reasons! 

1)  High  circuit  density.  One  reason  for  the  high  circuit  density  Is  that  there  are  no  n  and  p  wells 
as  In  the  twin  tub  process. 

2)  The  circuits  are  very  fast  because  of  the  saall  capacitance.  The  snail  capacitance  Is  due  to  the 
Insulating  substrate  which  leaves  only  a  capacitive  contribution  from  the  walls  of  the  source  and  drain. 
Also  because  of  the  insulating  substrate  leakage  currents  are  negligible  or  non  existent. 


3)  Latch  up  la  elialnated. 


The  problems  associated  with  body  effect  are  elialnated. 

SOI  has  the  potential  of  being  the  leading  CMOS  technology  of  the  future.  The  high  speeds  and  the 
high  densities  aake  this  technology  very  attractive.  It  also  changes  to  3D  quite  easily  with  devices  sharing 
a  common  gate  electrode. 

First  Order  Sealing  of  CMOS  Devices 

If  these  devices  are  Indeed  the  device  of  the  futture  then  the  next  question  Is  how  small  can  they 
be.  I  am  going  to  give  a  rather  quick  overview  of  first  order  scaling  and  you  can  nee  how  this  can  be 
extended.  This  first  order  sealing  Is  baaed  on  the  'constant  charge  aodel’  (Ref  3)  that  basically  says 
that  the  operational  characteristics  of  a  device  can  be  maintained  If  the  device  Is  scaled  by  a  factor 
of  A.  The  following  Is  then  scaled  with  this  dimensional  constant  A. 

1)  vertical  and  lateral  dlaensions 

2)  voltages 

3)  doping  concentrations 
The  actual  effect  Is  then. 


device  parameter 


scale  factor 


length 
width  W 

gate  oxide  thickness  t(ox) 
Junctln  depth  x(J) 
substrate  doping 
supply  voltage  V(dd) 

E  field  across  oxide 

depletion  layer  thickness 

parasitic  capacitance  WL/t(ox) 

gate  delay  VC/I 

DC  power  dissipation 

dynamic  power  dissipation 

power  speed  product 

gate  area 

power  density  VI/A 

current  density 

transconductance 


1/A 

1/A 

1/A 

1/A 

1/A 

A 

1/A 

1 

1/A 

1/A 

1/A»2  (•Hvralsed  to  the  power  of  2) 

1/A»2 

1/A''3 

1/A»2 

1 

A 

1  (Ref  It) 


Several  things  beeoae  Inawdlately  obvious  from  the  above!  first  as  we  decrease  channel  length  we  will 
have  to  Increase  doping  concentration  In  order  to  narrow  the  depletion  region.  You  can  see  the  current 
density  scales  llnearlly  and  the  line  widths  of  the  conductors  will  be  decreasing  ao  alectroalgratlon 
becoaes  a  real  problem  as  doss  IR  drops  along  these  conductors.  These  probleas  can  be  pointed  out  with 
yet  another  table. 


parameter  fhdor 


line  resistance  r  A 

line  response  rc  1 

normalized  line  response  A 

line  voltage  drop  1 

normalized  line  voltage  drop  A 

current  density  A 

normalized  contact  voltage  drop  A*2  (Ref  5) 


It  becomes  obvious  that  It  will  become  harder  to  take  advantage  of  the  fatter  devices  bscause  of  the 
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intercomieet  probleaa. 

The  firet  order  ecallng  rules  described  above  do  not  adequately  explain  device  behavior  In  the 
aubnlcron  raa^e.  I  will  give  a  list  of  reasons  why  first  order  sealing  Is  not  accurate  for  submicron 
geometries  sad  then  explain  bow  processing  changes  can  help  correct  these  probelms.  At  small  geometries 
large  doping  concentrations  are  used  to  prevent  threshold  voltage  falloff.  These  high  concentrations 
decrease  carrier  mobility  and  Increase  the  number  of  hot  electrons  (Ref  6).  By  hot  electron,  I  mean  an 
electron  that  has  an  energy  that  Is  more  than  a  few  kT  above  the  Rerml  level.  Vhen  these  hot  electrons 
beco'oe  Injected  into  the  gate  oxide  they  cause  gate  oxide  charging  and  consequently  change  the  threshold 
voltage  of  the  device.  These  hot  carriers  are  the  result  of  not  scaling  the  power  supply  voltage  and 
continuing  to  decrease  the  channel  lengths  of  the  device.  A  problem  with  scaling  voltages  to  eliminate 
these  effects  in  that  as  you  scale  down  threshold  voltages  you  are  bringing  the  device  "on”  conductance 
closer  to  the  device  "off*  conductance.  This  Implies  that  power  densities  cannot  remain  constant  but  will 
have  to  be  Increased.  Aslo  as  the  devices  become  smaller  and  smaller  we  will  be  talking  about  depletion 
layers  In  the  hundreds  of  angstroms.  As  electron  mean  free  paths  and  depletion  layers  become  about  the 
same  then  the  electrons  can  be  accelerated  through  the  thin  layers  without  scattering  thus  obtaining  veri- 
high  velocities k  these  effects  are  called  ballistic  effects. 

Also  as  doping  levels  are  Increased,  there  becomes  a  point  vhen  the  gate  oxide  breaks  before  eurface 
Inversion  can  take  place.  This  concentration  Is  above  lE-^l^  cm*-3  (Ref  T).  As  a  reference  point  the  surface 
concentration  for  a  channel  length  of  2000  angstroms  Is  between  lE+lT  and  lE-elS  cm*-3.  Another  problem 
Is  Interconnect  related.  As  line  widths  and  spacing  are  decreased  the  RC  delsy  factor  In  increased.  For 
large  pitch  metallization  a  parallel  plate  model  for  capacitance  Is  fairly  accurate,  but  as  the  metal 
runs  are  scaled  (  spacing  la  often  scaled  less  than  height  and  width)  fringing  effects  become  very 
improtant  In  adding  to  the  total  capacitance.  The  resistance  is  also  Increasing  so  we  can  show  a  large 
Increase  In  RC  related  delays.  This  again  points  to  the  laiportance  of  multilayer  metallization  for  Integrated 
circuits. 

Also  of  Importance  In  carrier  velocity  saturation.  As  the  channel  length  decreases  the  propagation 
delay  scales  llnearlly  lasted  of  as  the  square  of  the  channel  length.  This  velocity  saturation  occurs 
at  2EU  V/cm  for  electrons  and  lES  V/cm  for  holes  (Ref  9).  Therefore  the  carrier  mobility  for  holes  and 
electrons  become  nearly  equal  for  short  channel  devices.  This  fsct  could  eliminate  the  need  for  sizing 
of  RMOS  and  PMOS  translsors  In  the  future. 

The  problems  listed  above  are  Just  some  of  the  problems  associated  with  the  first  order  scaling  model. 
Scaling  Is  seldom  unlformlly  done  as  night  be  suggested  by  the  first  order  model.  Often  lateral  disienslons 
are  scal-;d  more  than  vertical  dimensions.  This  kind  of  scaling  makes  the  device  less  prone  to  failures 
but  also  has  adverse  effects  such  as  making  the  topography  quite  rough  and  hard  to  planarize.  Many  of 
the  problems  that  are  encountered  In  scaling  will  be  solved  by  new  materalls  and  new  IC  processing 
techniques.  /JLthough  the  two  processing  technologies  for  CMOS  mentioned  above  will  be  dominant.  But  there 
will  be  process  variations  to  continually  Improve  device  performance.  For  Instance  a  lot  of  work  Is  being 
done  to  minimize  hot  electron  effects.  Lightly  doped  drains,  doubly  doped  drains  and  doubly  diffused 
drains  that  form  a  step.  Even  with  Improving  technology  there  are  still  some  fundamental  limits  of  physics 
and  this  is  what  will  be  examined  next. 

Physical  Limits 

The  physical  limits  for  device  size  are  set  by  quantum  mechanics  and  thermodynamics.  Quantum  mechanics 
tells  us  that  for  each  eigenstate  of  a  system  there  Is  an  assocalted  energy  and  transition  between  states 
will  have  an  associated  radiation  or  absorption  of  energy.  So  we  have  a  quantization  of  energy  In  physical 
systems  (Ref  10).  The  lover  size  limit  of  a  FET  depends  on  the  discreteness  of  charge  and  the  wave  nature 
of  electrons.  The  wave  equation  Is  then  given  by  U>e(lkx)  and  for  the  one  dlwnslonal  barrier  problem 
we  will  have  three  cases,  E  greater  than  V,  E>V,  E  less  than  V.  The  case  of  transmission  with  energy  less 
than  V  Is  a  purely  quantum  mechanical  effect  and  Is  called  tunneling.  For  the  conventional  transistor 
to  operate  properly  the  current  due  to  tunneling  must  be  smaller  than  the  other  currents  In  the  transistor. 

Next  from  thermodynamics  we  can  discuss  the  entropy  of  a  system  or  from  the  second  lav  of  thermodynamics 
an  Increase  of  order  In  one  part  of  a  system  la  matched  by  an  even  greater  Increase  of  disorder  in  another 
part  of  the  system.  In  other  words  entropy  is  alvay  Increasing  In  the  universe.  So  with  this  In  hand  we 
can  talk  about  switching  energies.  To  switch  '  jtveen  an  high  and  a  low  state  the  energy  must  be  large 
as  compared  to  thermal  energy  kT.  Theorltlcally  s  minumum  switching  energy  of  kT  Is  required.  Whether  a 
workable  system  can  be  made  with  thir  low  energy  Is  questionable.  The  above  shows  that  the  low  voltage 
limit  depends  on  the  charge  of  an  electron  and  thermal  fluctuation. 

Conclusion 

This  paper  has  concentrated  on  CMOS  devices  because  X  feel  MOS  technology  will  continue  to  be  the 
technology  of  the  1990's  and  Into  the  21st  century.  I  think  I  have  shown  that  advances  In  processing 
technology  and  new  materials  will  continue  to  shrink  device  dimensions  thus  Increasing  speed  and  density. 

This  In  no  way  Implies  that  there  won't  be  a  demand  for  or  Improvements  In  other  technologies.  I  don't 
think  that  there  Is  any  question  that  silicon  will  continue  to  be  the  most  widely  used  technology  Into  the 
next  century.  There  will  still  be  specific  needs  for  the  very  high  speed  of  gallium  arsenide.  There  will 
be  continued  research  Into  hot  electron  devices  and  quantum  devices.  But  as  CMOS  speeds  continue  to 
Increase  the  range  of  uses  for  this  technology  continue  to  expand. 
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SUMMARY 

Based  on  a  review  of  human  engineering  activities  in  ten  major  acquisition  projects,  this  paper  outlines  some  con¬ 
clusions  aimed  at  facilitating  the  integration  of  human  engineering  activities  with  the  development  of  advanced  avionics. 
Conclusions  are  also  drawn  about  the  systems  design  and  human  engineering  processes,  and  the  role  that  mission,  func¬ 
tion,  and  task  analyses  can  play  in  integrating  human  engineering  and  systems  development  activities.  It  is  concluded 
that  an  approach  which  combines  the  interaction  of  hardware,  software,  and  human  functions  is  made  especially  neces¬ 
sary  by  the  impact  of  advanced  technology  on  the  roles  of  human  operators  and  maintainers,  on  the  man-machine  inter¬ 
face,  and  on  the  system  development  process  itself.  Finally  it  is  argued  that  there  is  a  need  to  establish  standardized 
approaches  to  the  application  of  human  engineering  in  avionics  system  design. 

INTRODUCTION 

Human  Engineering  (HE)  and  Systems  Engineering  (SE)  were  introduced  as  formal  disciplines  in  response  to  the 
technological  advances  of  thirty  to  forty  years  ago.  It  was  soon  apparent  that  Human  Engineering  should  be  an  integral 
part  of  Systems  Engineering,  as  implied  in  one  of  the  earliest  SE  texts  (1).  This  lead  to  the  concept  of  the  ’’systems 
approach"  to  HE.  The  inclusion  of  HE  in  SE  activities  is  reiterated  in  more  recent  publications  (2,3). 

As  avionics  improvements  have  introdueed  increasing  leveb  of  automation  over  the  past  forty  years,  so  the  human 
factor  in  systems  performance  has  become  increasingly  'mportant.  Despite  th'is,  and  despite  the  attention  being  paid  to 
human  engineering  in  some  advanced  projects,  the  integration  of  HE  with  the  systems  design  process  continues  to  be 
problematic.  A  review  conducted  at  thb  Institute  (4)  concluded  that  it  is  more  likely  that  the  HE  aspects  of  system 
design  will  be  overlooked  or  neglected  than  incorporated.  Discussing  reasons  for  this  lack  of  Integration,  a  Panel  at  the 
1084  NATO  DRG  Panel  VIII  Workshop  on  Applications  of  Systems  Ergonomics  to  Weapon  System  Development  recom¬ 
mended  that  case  studies  be  compiled  and  stucUed  for  lessons  learned  (5). 

This  paper  is  a  partial  response  to  that  suggestion.  The  application  of  HE  in  ten  projects  involving  advanced 
avionics,  or  similar  technology,  in  which  DCIEM  scientists  were  HE  advisors  to  the  procuring  agency,  is  reviewed.  The 
review  examines  the  application  of  HE  throughout  the  systems  development  process.  The  impact  of  advanced  technol¬ 
ogy  on  the  systems  development  process  b  discussed.  Problems  which  arose  at  each  stage  are  categorized  as  due  to 
either  management  issues,  or  to  HE  procedures  and  techniques. 

IMPACT  OF  ADVANCED  TECHNOLOGY  ON  SYSTEMS  DEVELOPMENT 

The  projects  which  were  reviewed  date  from  1972  to  the  present.  They  include  both  development  and 
evaluation/seleetion  activities  for  1  single  seat,  and  5  multi-piBce  aircraft,  and  4  similar  combat  information  systems. 
All  included  advanced  technology  and  complex  man-machine  interfaces. 

A  key  feature  of  these  interfaces  b  that  the  technology  used  has  many  more  "degrees  of  freedom’  than  older  tech¬ 
nology.  Therefore  it  provides  more  opportunities  to  make  sub-optimal  design  trade-olb,  especially  in  the  interactions 
between  different  parameters.  For  example  in  electro-mechanical  dbplays,  which  are  reflective,  contrast  of  the  charac¬ 
ters  or  legends  b  dictated  by  the  selection  of  paint  for  the  background  and  the  markings,  and  the  control  of  veiling  glare 
on  the  instrument  glass.  Contrast  on  a  similar  CRT  dbpiay  b  a  function  of  character'wtics  such  as  brightness  and  Inten¬ 
sity  setting,  dynamic  contrast  of  the  CRT,  phosphor  type,  shadow  mask  characteristics,  reflection  from  two  or  three 
intervening  surfaces,  and  transmbsion  characteristics  of  a  notch  Alter. 

Another  feature  of  advaneed  teehnology  b  that  It  impfles  significant  changes  in  the  roles,  funct’ions,  and  tasks  per¬ 
formed  by  the  human  operator.  Such  changes  increase  the  importance  of  Integrating  HE  activities  from  the  outset  of 
system  development. 

The  man-machine  interfaces  associated  with  such  advanced  technology  are  extremely  flexible.  They  can  provide  an 
extremely  large  amount  of  in  formation  to  the  operator,  and  they  can  change  as  a  result  of  operator  action  or  the  opera- 
tional  or  environmental  situation.  Therefore  the  operator  must  maintain  not  only  a  current  mental  model  of  the  opera- 
/  tional  situation  and  of  the  system  state,  but  also  a  model  of  the  Interface,  and  where  he  b  In  the  multi-page  representa¬ 

tion  of  the  system  and  environment.  The  design  of  these  systems  therefore  requires  a  more  thorough  analysb  than  did 
more  traditional  interfaces.  Unfortunately  the  availability  of  such  Interfaces,  and  their  superficial  similarity,  encourages 
I-  systems  designers  to  quickly  estabibh  a  design  concept  based  on  such  equipment.  This  leads  to  the  deferment,  or 

I  neglect  of  important  questions  of  concerning  the  roles,  functions,  and  tasks  of  the  operators,  and  exactly  bow  the  equlp- 

r*  ment  will  be  used,  what  Information  will  be  dbplayed,  when,  and  to  whom,  and  what  controb  will  be  provided.  The 

f  postponement,  or  neglect,  of  HE  Issues  has  repercussions  for  several  aspects  of  system  design,  as  will  be  discussed  below. 


27-2 


HUMAN  ENGINEERING  AND  SYSTEMS  DEVELOPMENT 

In  the  Chadian  Forcea  the  approach  to  the  application  of  human  engineering  in  acquisition  projects  is  based  on 
that  used  by  the  US  services  (ft).  In  many  cases  the  same  work  items  and  design  standards  are  used.  The  current  stan¬ 
dard  which  specifies  the  approach  to  human  engineering  MIL-H-46855B  (7)  assumes  a  sequence  of  stages  in  system 
design  development  which  parallels  the  general  stages  recommended  for  Systems  Engineering  (Table  1). 

In  our  experience  that  recommended  procedure  is  not  always  followed  in  practice.  Seldom  b  there  a  systematic 
March  for,  and  evaluation  of,  candidate  system  concepts,  followed  by  system  development.  Rather,  the  preferred  concept 
b  often  identified  very  quickly,  based  on  precedent,  and  the  remaining  systems  development  effort  b  devoted  to  making 
that  concept  work.  In  thb  respect  the  process  b  much  doner  to  what  has  been  called  the  "ad  hoc"  or  "direct"  approach 
to  systems  design  (8),  rather  than  the  "standard"  approach  which  includes  either  theoretical  or  experimental  modelling 
and  simulation.  Athans  (8)  has  noted  that  the  direct  approach  b  often  used  for  the  design  of  the  overall  system,  with 
the  standard  approach  being  used  for  sub-systert.  optimization. 

Although  the  direct  approach  b  understandable  in  terms  of  the  cost  savings  involved,  it  has  obvious  limitations, 
and  those  limitations  are  exacerbated  by  advanced  technology.  In  particular  it  encourages  the  tendency  to  base  human 
engineering  decisions  on  solutions  to  previous  problems,  rather  than  analysis  or  experimentation.  In  reviewing  the  such 
problems  in  the  context  of  the  systems  development  process,  the  general  project  management  headings  of  Technical 
Planning  and  Control,  Systems  Engineering  Process,  and  Engineering  Speciality  Integration  (3)  were  used. 

Table  1.  Recommended  Stages  in  Systems  Engineering  and  Human  Engineering  Analysis 


Systems  Engineering 

Systems  Engineering 

Human  Engineering 

Hall  -  Ref  14. 

MII>-STD-40flA 

MIL-H-46868B 

Problem  Definition 

Mission  llequireinenLs 

Analysb 

Preparation  of  Scenarios  and  Mission 
Profiles 

Value  System  Design 

- 

- 

System  Synthesis 

Functional  Analysis 

Definition  of  Functions; 

Information  Flow  and  Processing 
Analysb. 

.System  Analysb 

Allocation 

Estimates  of  Potential  Operator  Capa¬ 
bilities; 

Allocation  of  Functions 

System  Analysb 

Synthesb 

Gross  Analysb  of  Tasks; 

Analysis  of  Critical  Tasks 

Optimization 

Optimization 

Workload  Analysis; 

Preliminary  System  and  Sub-system 
Design; 

Equipment  Detail  Design; 

Studies,  Experiments,  Laboratory 
Tests; 

Procedures  Development 

Decision  Making 

lx>gistic  Engineering; 

Life  Cycle  Cost  Analysb 

Test  and  Evaluation 

TECHNICAL  PROGRAM  PLANNING  AND  CONTROL 

This  b  defined  as  the  "..management  of  those  design,  development,  test,  and  evaluation  tasks  required"  (3).  In  the 
projects  reviewed,  planning  and  control  factors  which  infiuenced  the  integration  of  HE  with  SE  in  included  management 
approach  to  HE,  organization,  stafiing,  planning,  and  scheduling. 

Management  Approach  to  Human  Engineering 

In  1061  Melton  (0)  noted  that  the  concept  of  a  systems  approach  to  human  engineering  had  leas  acceptance  and 
was  implemented  less  often  than  "...a  casual  examination  of  regulations,  mbsion  assignmenU,  contract  clauses,  and 
research  and  development  project  statements  might  imply".  He  argued  that  thb  was  In  part  because  management  had 
not  fully  adapted  to  the  concept,  and  In  part  because  not  all  human  engineering  speelalbts  had  the  time  or  opportunity 
to  experience  the  sysUms  approach  to  HE.  Our  experience  Indicates  that  the  same  holds  true  today:  many  involved  In 
project  management  have  yet  to  adapt  to  the  need  for  human  engineering,  and  few  engineers  or  systems  deslgnen  have 
experience  of  successful  applications  of  HE  to  several  advanced  projects. 
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The  management  approach  to  HE  most  frequently  encountered  is  that  it  U  a  factor  in  the  detailed  aspects  of  inter¬ 
face  and  wwkspace  d«ign  exemplified  by  the  various  design  guides  or  "cookbooks”,  and  covered  under  th^  headings  of 
bystem,  Sub-system,  Equipment,  Work  Environment,  and  Crew  Station  Facilities  Design  in  MIL-H-46855B  (7)  In  half 
of  the  projects  reviewed,  the  HE  activities  were  associated  with  design  efforts,  rather  than  with  SE  efforts  H-able  2). 
Such  an  approMh  does  not  ensure  that  the  benefits  of  advanced  technology  will  be  realised,  aince,  as  indicated  above, 
the  human  engineering  analyses  required  to  optimise  system  performance  are  required  prior  to  the  design  stage. 


Table  2.  Human  Engineering  Invnivement  in  Project  Development 


HE  Effort  Project  No. 

1 

2 

3 

4 

5 

6 

7 

8 

0 

10 

Planning  (HEPP) 

x/ 

- 

x/ 

- 

- 

- 

v' 

x/ 

x/ 

x/ 

Systems  Analysis 

s/ 

- 

%/ 

- 

x/ 

- 

x/ 

t 

- 

x/ 

De-sign 

s/ 

x/ 

x/ 

v/ 

x/ 

x/ 

x/ 

x/ 

x/ 

Test  and  Kvaiaation 

s/ 

■ 

y 

- 

x/ 

- 

x/ 

x/ 

T.B.D 

Ilfi  Sta^  Qualificd/Elxpenenced 

x/ 

- 

x/ 

- 

- 

- 

- 

x/ 

- 

x/ 

Organisation  and  Staffing 

If  Human  Engineering  is  to  be  applied  as  part  of  systems  analysis,  it  seems  clear  that  it  should  be  part  of  the  Sys¬ 
tems  Engineering  function.  Goode  and  Machol  (1)  addressed  the  organisation  of  SE  functions,  and  argued  that  although 
some  organisations  were  not  effective,  severed  different  types  of  organisations  can  work,  depending  on  the  personnel 
involved.  The  same  appears  to  be  true  of  the  organisation  of  the  HE  effort.  When  HE  has  been  included  as  part  of  Sys¬ 
tems  Engineering,  it  has  been  one  of  the  branches  of  the  SE  management  tree.  This  locates  the  HE  function  in  the  right 
place,  but  it  does  not  guarantee  that  HE  issues  are  treated  effectively  because  they  are.  in  many  instances,  orthogonal  to 
other  engineering  considerations.  There  is  a  need  to  integrate  the  human  engineering  contribution  with  other  engineer¬ 
ing  efforts  through  the  techniques  and  procedures  by  which  design/development  issues  are  handled. 

Integration  cannot  be  achieved  merely  by  making  systems  engineers  responsible  for  HE.  Despite  their  similarity  to 
systems  engineering  techniques,  the  current  HE  techniques  seem  to  require  training  or  experience.  Yet  in  only  four  of 
the  ten  projects  reviewed  were  the  contractor's  HE  personnel  trained  or  experienced.  A  variety  of  staffing  arrangements 
were  used,  ranging  from  the  senior  mechanical  draftsman  being  responsible  for  human  engineering,  to  all  engineers  being 
responsible  for  human  engineering.  Neither  of  these  extremes  proved  satisfactory  because  they  did  not  ensure  that  those 
responsible  for  the  HE  function  were  knowledgeable  in  the  latest  developments,  particularly  in  Function,  Task,  and 
Workload  Analysis. 

Three  recent  projects  demonstrated  the  importance  of  that  knowledge.  Systems  engineers  given  the  responsibility 
for  HE  analyses  such  as  Functional  Analysis,  Potential  Operator  Capabilities  Report,  Function  Allocation,  Task 
Analysis  and  Workload  Prediction,  bad  problems  in  understanding  either  the  utility  of  the  technique,  or  bow  it  related 
to  other  engineering  activities.  In  two  projects  they  could  not  understand  the  utility  of  Functional  Analysis,  or  of  a 
review  of  Potential  Operator  Capabilities.  In  one  of  those  projects  they  argued  that  since  the  operators  perform  all  the 
tasks  associated  with  current  manual  systems,  any  more  iidvanced  system  was  bound  make  those  tasks  easier.  In  the 
third  project  the  HE  activities  were  planned  by  one  company  of  a  consortium,  for  implementation  by  another  company 
with  no  experience  in  HE.  Those  made  responsible  for  HE  argued  that  the  Function  and  Task  Analyses  were  implicit  in 
the  way  the  system  had  been  conceived,  and  that  no  other  analysis  was  necessary.  In  fact,  no  analysis  of  bow  the  sys¬ 
tem  would  be  operated  or  maintained  had  been  performed;  the  contractor  bad  no  rationale  for  the  operator  and  main- 
tainer  tasks,  the  interface  design,  equipment  procedures  or  training  plan.  As  a  result  changes  identified  as  necessary 
through  Test  and  Evaluation  were  implemented  in  a  piecemeal  fashion,  with  no  understanding  of  their  impact  on  sys¬ 
tem  performance. 

Convincing  systems  engineers  of  the  value  of  such  analyses,  and  obtaining  analyses  of  an  acceptable  standard  would 
have  been  easier  if  clear,  comprehensive,  worked  examples  of  each  technique  had  Seen  available.  Although  the  human 
factors  literature  contains  examples  of  the  more  common  techniques  such  as  the  Function  Flow  Block  Diagram,  no  gen¬ 
eral  purpose  guide  has  been  found  which  covers  the  development  and  use  of  all  techniques. 

Planning  and  Scheduling 

Advanced  technology  has  a  significant  impact  on  the  planning  and  scheduling  of  hunan  engineering  activities.  The 
tendency  to  design  the  man-machine  interface  without  scheduling  an  adequate  amount  of  effort  in  the  analysis  stage  has 
already  been  mentioned.  A  more  fundamental  problem  arises  because  it  is  possible  to  introduce  advanced  technology  at 
a  raster  rate  than  it  is  puesibie  to  undeistand  the  human  engineering  issues  involved,  or  how  best  to  use  that  technology. 
For  example  recent  work  at  this  Institute  shows  that  basic  questions  regarding  the  Implementation  of  electro-optical 
colour  displays  are  complex  and  poorly  understood.  Despite  the  lack  of  understanding,  such  displays  are  entering  service 
in  Increasing  numbers. 

The  overall  pace  of  development  of  such  technology  must  be  anticipated.  In  two  of  the  most  recent  projects 
reviewed,  the  need  to  have  the  emerging  technology  implemented  In  the  "next"  system,  rather  than  missing  the 
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opportunity  by  10  to  15  years,  resulted  In  technology  implementation  being  rushed.  There  was  a  rapid  transition  from 
Concept  Development  to  Design  for  Production,  with  insufficient  exploration  or  development  of  the  concept.  Thus  the 
operator’s  tasks  were  not  analyzed  thoroughly,  and  the  impact  of  the  new  technology  on  operator  roles,  and  the  rela- 
tionship  between  senior  and  junior  personnel  was  not  investigated.  No  man-in-the-loop  simulation  was  undertaken, 
despite  the  obvious  need  for  such  experimentation. 

The  key  to  the  successfui  scheduling  of  HE  activities  is  the  Human  Engineering  Program  Plan  (7,  10).  The  HEPP 
specifies  the  organization,  scheduling,  and  extent  of  HE  effort,  and  how  that  effort  will  be  integrated  with  others  in  the 
systems  development  process.  Somewhat  surprisingly,  four  of  the  advanced  technology  projects  reviewed  did  not  use 
such  a  plan,  and  in  one  case  the  plan  was  scheduled  for  delivery  8  months  into  the  project.  The  surprise  is  in  part  due 
to  the  fact  that  the  HEPP  is  a  standard  contract  requirement.  The  importance  of  the  HEPP  for  the  attitude  behind  its 
use]  is  indicated  by  the  use  of  the  different  HE  techniques.  Those  projects  which  had  an  HEPP  involved  an  average  of  6 
of  the  analysis  activities;  those  without  an  HEPP  involved  an  average  of  2  HE  analysis  activities. 

Continuity  of  Approach 

The  man-machine  interface  in  advanced  technology  systems  is  characterized  by  a  large  amount  of  information,  and 
a  large  number  of  control  options.  One  example,  the  F-18  interface,  has  already  been  discussed  in  AGARD  (11);  over  200 
menu  options  are  available  through  12  major  display  pages  on  two  CRT  displays,  and  the  HUD  display  has  15  major 
modes.  Such  complexity  makes  it  difficult  to  ensure  the  continuity  of  approach  to  the  interface  as  a  system  is 
developed.  Elstablishing  and  maintaining  a  rigorous  application  of  rules  for  the  use  of  spatial,  colour,  intensity,  or  sym¬ 
bolic  display  coding  is  extremely  difficult,  as  others  have  noted  (12). 

In  addition,  display  format  'configuration  control”  is  a  major  problem.  In  one  recent  case,  carefully  established 
conventions  on  symbology  and  display  formatting  were  compromised  by  last  minute  changes  to  the  software.  In  another 
case,  what  was  to  have  been  an  off-line  display  became  a  primary  display  because  of  shortcomings  in  the  capacity  of  the 
computer  handling  tactical  information.  Predictably  the  operators  routinely  complain  about  the  human  engineer  who 
placed  one  of  their  principal  displays  in  a  scarcely  accessible  location.  It  is  therefore  important  to  maintain  good 
records,  not  only  of  what  rules  were  developed,  but  of  the  HE  rationale  for  those  rules. 

SYSTEMS  ENGINEERING  PROCESS 

Systems  Engineering  involves  ”the  sequence  of  activities  and  decisions  transforming  an  operational  need  into  a 
description  of  system  performance  parameters  and  a  preferred  system  configuration"  (3).  The  HE  process  implied  by 
MIL-H-48855B  involves  such  a  sequence  of  activities  through  analysis,  design,  test  and  evduation.  The  overall  approach 
used  in  such  analyses  has  been  outlined  in  the  work  of  AGARD  Avionics  Panel  Working  Group  08  (13).  It  parallels  that 
recommended  for  Systems  Engineering  (3,  14),  as  shown  in  Table  1,  although  it  differs  in  the  emphasis  on  analysis 
rather  than  mathematical  modelling  and  optimization. 

Table  3  shows  the  use  made  of  the  different  analysis  techniques  for  the  ten  projects  reviewed.  Only  one  or  two 
techniques  were  used  in  some  projects.  Interestingly  those  projects  involved  the  most  technology  development,  for 
example  the  development  of  a  digital  data  bus  and  general  purpose  man-machine  interface.  The  majority  of  the 
projects  used  most  of  the  standard  HE  techniques,  but  in  different  ways,  and  to  different  degrees. 

Table  3.  Human  Engineering  Analysis  Activities  in  Individual  Projects 


HE  Activity  Project  No. 

1 

2 

3 

A 

5 

6 

7 

8 

0 

10 

Mission  Analysis 

V 

si 

V 

- 

- 

- 

x/ 

- 

sl 

sl 

Definition  of  Functions 

v/ 

- 

■ 

si 

- 

si 

- 

- 

sl 

Information  Flow  &  Processing 

. 

. 

- 

si 

. 

. 

Analysis 

Estimates  of  Potential  Operator 

. 

•* 

. 

si 

. 

. 

sl 

Processing  Capability 

Allocation  of  Fui  ctions 

x/ 

- 

si 

■ 

- 

- 

si 

- 

- 

sl 

Gross  Analysis  of  Tasks 

v/ 

s! 

si 

- 

si 

si 

si 

sl 

sl 

x' 

Analysis  of  Critical  Tasks 

x/ 

- 

si 

■ 

- 

- 

sl 

- 

sl 

- 

Workload  Analysis 

x/ 

s! 

sj 

- 

- 

- 

si 

- 

- 

si 

Studies,  Experiments,  Lab  Tests 

x/ 

■ 

si 

si 

si 

- 

■ 

- 

sl 

- 

Mission  Analysis 

Mission  Analysis  is  equivalent  to  the  SE  stage  of  Problem  Definition  (14),  or  Mission  Requirements  Analysis  (3). 
The  lack  of  any  Mission  Analysis  In  4  of  the  projects  reviewed  Indicates  that  its  utility  Is  not  fully  understood.  It  is  a 
vital  prerequisite  to  HE  analysis,  because  it  sets  the  requirements  for  what  the  manned  system  is  expected  to  do.  Thus 
It  should  be  done  thoroughly,  and  from  the  perspective  of  a  manned  system.  In  one  recent  project,  mission  analyses 
were  prepared  to  show  the  air  vehicle  transmission  loadings.  Pilot  activity  was  Implicit  in  those  loadings,  but  the  ana¬ 
lyses  could  not  be  used  as  the  basis  for  HE  analyses  without  being  reworked. 
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In  conducting  mission  analyses  it  is  essential  to  use  realistic  scenarios,  and  to  describe  the  most  demanding  mis¬ 
sions.  Operational  problems  which  have  arisen  in  at  least  two  of  the  systems  reviewed  are  directly  attributable  to  the 
use  of  unrealistic  missions.  For  example,  communication  with  other  units  is  a  significant  factor  in  operator  workload  in 
many  modern  systems.  In  one  project  the  original  mission  and  task  analyses  had  low  levels  of  communication,  commen¬ 
surate  with  routine  usage.  Original  estimates  of  workload  were  3  on  a  scale  of  1  to  5.  Operational  experience  confirms 
those  ratings  for  the  missions  which  were  analyzed,  but  missions  which  were  not  analyzed  are  being  rated  at  ”5  -  exces¬ 
sive  workload”. 

Definition  of  Functions 

Function  Definition  is  a  logical  extension  of  the  process  initiated  with  Mission  Analysis,  and  again  is  directly  com¬ 
patible  with  SE  activities.  The  HE  activities  associated  with  the  Definition  and  Allocation  of  Functions  are  intended  to 
ensure  that  the  functions  of  the  operators  and  maintainers  are  derived  from  systematic  consideration  of  the  mission 
requirements.  This  is  not  always  done;  five  of  the  projects  reviewed  did  not  include  a  systematic  Definition  of  Func¬ 
tions.  In  two  of  the  projects  where  functions  were  defined  the  contractors  had  difficulty  conducting  an  analysis  of  the 
functions  currently  performed  by  human  operators.  They  also  had  difficulty  conducting  the  analyses  down  to  the 
required  level  of  detail,  where  functions  can  be  unambiguously  allocated  to  man,  hardware  or  software. 

Analyzing  the  functions  to  be  performed  by  the  human  operators  is  understandably  difficult.  Whereas  Goode  and 
.Vlachol  (1)  viewed  the  primary  objective  of  HE  as  optimizing  the  man-machine  link,  many  human  engineers  hold  the 
view  that  HE  is  the  study  of  the  human  compouenis  of  systems,  and  the  integration  of  those  components  with  other 
system  components.  These  two  viewpoints  illustrate  a  fundamental  problem  in  Human  Engineering.  Man  is  both  a  sys¬ 
tem  user  and  a  system  cemponent.  The  former  viewpoint  encourages  an  approach  to  system  design  which  treats  man  as 
somehow  external  to  the  system  -  someone  who  receives  information  and  makes  inputs  to  the  system.  The  latter 
viewpoint  encourages  an  approach  which  integrates  consideration  of  what  the  user  does  with  what  other  system  com¬ 
ponents  do.  Both  attitudes  are  important,  because  human  operators  also  perform  functions  such  as  supervision,  check¬ 
ing,  and  training,  by  virtue  of  their  being  system  components. 

The  development  of  the  CP-UO  Aurora  aircraft,  which  is  one  of  the  projects  reviewed,  illustrates  the  importance  of 
both  attitudes.  One  of  the  most  notable  features  of  the  Aurora  is  that  the  six  tactical  operators  are  seated  together  in  a 
U  shaped  crew  compartment.  The  advantages  that  were  anticipated  for  that  layout  included  facilitation  of  a  team 
approach,  task  sharing,  consultation,  reversionary  mode  operation,  crew  rotation,  crew  interaction,  on-the-job  exposure 
to  more  senior  tasks,  crew  proficiency  training,  and  monitoring  of  crew  performance.  Of  418  potential  tasks  for  two 
operators,  106  were  judged  to  be  facilitated  by  the  adoption  of  the  integrated  compartment.  Yet  none  of  the  functional 
analyses  conducted  for  the  Aurora,  and  none  of  the  analyses  for  three  other  projects  which  have  been  reviewed,  include 
functions  which  reflect  such  activities  as  consultation,  training  and  monitoring.  Those  functions  derive  from  their 
impact  on  the  performance  of  the  human  operators,  but  do  not  derive  from  a  Functional  Analysis. 

Allocation  of  Function 

This  stage  of  analysis  is  again  directly  compatible  with  the  SE  process.  Geer  (15)  noted  that  there  are  three 
approaches  to  Allocation  of  Function:  "trial  and  error"  substitution  of  alternatives  into  a  system  or  sub-system  model; 
an  evaluation  matrix  of  plausible  operator  roles  and  equipment  functions  based  on  qualitative  performance  capabilities; 
an  evaluation  matrix  using  weighted  performance  scores  for  different  functions.  Only  4  of  the  projects  reviewed  used  a 
formal  approach  to  Allocation  of  Functions,  and  of  there,  only  3  are  believed  to  have  used  such  techniques  (only  two 
were  documented).  Other  projects  presumably  used  the  traditional  "ad  hoc”  approach  to  deciding  the  operator  and 
maintainer  functions.  This  b  undesirable  because  there  b  a  tendency  for  operators  and  maintainers  to  be  allocated 
those  functions  which  are  not  easily  engineered.  Thb  accounts  for  the  observation  that  most  military  roles  involve  either 
sensing,  deebion  making,  or  complex,  adaptive  manual  materiab  handling. 

Notwithstanding  current  efforts  (16),  advanced  technology  makes  it  increasingly  difficult  to  allocate  functions  on  a 
rational  basis.  The  capabilities  of  technologies  such  as  Expert  Systems  or  Direct  Voice  Input  are  difficult  to  estimate, 
and  their  optimum  use  to  complement  human  capabilities  and  limitations  is  difficult  to  determine  in  advance  of  opera¬ 
tional  use.  In  our  experience  it  b  difficult  for  designers  to  envbage  new  functions,  or  for  operators  to  envisage  how  new 
capabilities  will  be  used  and  exploited.  The  trade-off  of  task  complexity  against  selection  and  training  is  particularly 
difficult,  despite  implications  to  the  contrary  in  the  human  factors  literature. 

One  aid  to  such  problems  b  the  analysb  of  Potential  Operator  Processing  Capabilities  (7).  That  analysis  reviews 
what  operators  might  be  able  to  do  in  a  new  system,  in  terms  of  their  ability  to  process  information.  We  have  not 
experienced  much  success  with  it.  In  only  2  of  the  projects  reviewed  was  there  a  systematic  study  of  Potential  Operator 
Processing  Capabilities.  In  both  cases  they  were  contract  requirements  and  in  one  of  those  cases  the  purpose  of  the 
analysb  was  mbunderstood  by  the  contractor.  The  contractor’s  report  discussed  the  possible  effects  of  environmental 
stress  on  operator  performance,  rather  than  the  basic  capabilities  of  the  operators  to  perform  anticipated  functions.  Yet 
it  b  the  POPC  Analysis  which  formally  provides  information  on  what  operators  and  maintainers  can  be  expected  to  do. 
It  can  make  a  significant  contribution  to  two  of  the  formal  Function  Allocation  techniques  (15),  and  assist  In  resolving 
problems  about  task  complexity  and  training. 

Task  Analysb 

Task  Analysb  describes  the  actions  of  operators  (and  maintainers),  derived  from  the  Allocation  of  Functions,  for 
use  in  workload  prediction,  equipment  design,  equipment  procedures  development,  training  system  design,  and  develop¬ 
ment  of  performance  characterbtics  for  Test  and  Evaluation.  In  fact  the  preparation  of  'Task  Analyses  can  serve  as  an 
integrating  function  for  those  developmental  activities.  It  b  undoubtedly  a  reflection  of  its  utility  that  some  form  of 
Task  Analysb  was  undertaken  in  9  of  the  10  projects  reviewed.  Unfortunately  the  analyses  were  not  always  carried  out 
at  the  right  time,  or  to  the  most  effective  ievei  of  detail. 

In  5  out  of  8  projects  involving  multi-functton  dbplays  and  eontrob,  designers  established  the  man-machine  Intei^ 
face  well  before  conducting  detailed  task  analyses.  In  every  case  the  final  dtaplay  requirements  were  underestimated.  In 
three  cases  dbplays  could  not  be  optimized  because  of  constraints  Imposed  by  those  early  decisions.  In  three  eases  the 
operational  sequences  required  to  use  the  dbplays  and  eontrob  were  unsatisfactory,  being  too  complex  or  Inefficient.  In 
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one  such  case  where  the  location  of  displays  and  controls  had  to  be  modifled,  a  sub-contractor  concluded  after  the  event 
that  the  most  effective  approach  to  workplace  design  is  to  await  the  completion  of  system  analysis  and  then  design  the 
workplace. 

The  operation  of  all  of  the  interfaces  of  a  system  must  be  considered  in  such  analyses.  In  one  project  one  particular 
operator-machine  interface  was  analyzed  and  used  as  the  basis  for  the  design  of  the  whole  multi-operator  system.  Sub¬ 
sequently  some  preferred  display  formats  had  to  be  modified  to  suit  the  constraints  imposed  by  the  general  purpose 
interface.  The  premature  decision  on  the  interface  also  resulted  In  the  adoption  of  a  shadow-mask  colour  display  for  all 
functions,  whereas  the  subsequent  task  analyses  showed  that  high-resolution,  monochrome  displays  were  required  for 
some  of  the  system  sensors. 

Task  Analyses  must  not  only  be  timely,  they  must  be  complete.  In  one  project  Mission  Analyses  were  not  con¬ 
ducted,  and  Task  Analyses  were  conducted  for  only  the  engagement  sequences  of  the  basic  weapon.  No  analyses  were 
conducted  for  the  larger  system  of  which  the  weapon  is  a  part.  As  a  result  there  is  an  on-going  debate  as  to  how  best  to 
handle  information  from  other  platforms,  and  whether  operators  will  have  the  time  to  handle  tactical  information,  or 
will  be  able  to  respond  only  to  voice  messages.  The  system  was  not  designed  as  a  true  system,  but  as  a  number  of 
independent  units,  with  the  assumption  that  the  users  will  somehow  make  it  work. 

The  majority  of  Task  Analyses  are  conducted  at  a  "gross"  or  "upper”  level.  Critical  Task  Analysis,  as  defined  by 
(7),  seems  to  be  used  rarely.  In  fact  we  have  never  seen  a  Critical  Task  Analysis  which  provided  all  the  information 
required  by  MIL-H-46855B.  When  detailed  task  analyses  have  been  produced  they  have  usually  been  Operational 
Sequence  Diagrams  (OSDs)  (13,  15).  Five  of  the  10  projects  used  such  an  approach.  OSDs  do  not  provide  all  the  neces¬ 
sary  information,  however,  because  they  do  not  readily  indicate  the  required  performance  standards,  the  impact  of 
operator  error,  or  the  necessary  job  skills. 

Analyzing  the  impact  of  operator  error  is  increasingly  important  ’  ales  of  operators  and  maintainers  change 
to  those  of  a  system  monitor  and  supervisor.  In  one  project,  w,  .i  '  ■'u  the  development  of  a  general  purpose  com¬ 
munication  system,  the  contractor  described  the  operation  of  the  system  using  Signal  Flow  Graphs,  or  State  Graphs. 
This  technique  is  often  used  to  describe  communication  systems.  However  the  graphs  were  used  to  describe  only  the 
correct  operational  sequences.  They  did  not  describe  incorrect  sequences  (the  graphs  become  much  more  complex  if  this 
is  done),  and  as  a  result  they  did  not  show  that  it  was  possible  for  an  operator  to  dismantle  a  whole  communications  net 
if  he  made  one  particular  error. 

Workload  Analysis 

In  only  4  of  the  projects  reviewed  was  there  a  formal  Workload  Analysis.  Again,  the  problems  introduced  by 
advanced  technology  require  that  far  greater  use  is  made  of  this  technique.  As  others  have  noted  (U,  17),  advanced 
technology  can  add  to  the  workload  of  the  operator  or  maintalner.  With  Its  emphasis  on  Information,  advanced  ,  tech¬ 
nology  encourages  systems  developers  to  display  "all  possible"  information  to  the  user(s).  This  is  typified  by  the 
development  history  of  the  HUD,  Helmet  Mounted  Displays,  and  multi-function  CRT  dbplays.  As  others  have  pointed 
out  (11,  17),  such  information  is  not  usually  integrated,  and  can  increase  operator  workload  unless  the  conditions  under 
which  it  is  used  have  been  carefully  defined. 

In  one  recent  project,  the  original  concept  had  34  pages  of  information;  engineering  developments  increased  that  to 
71,  with  a  disproportionate  increase  in  the  complexity  of  the  menu  selection  sequence.  During  trials  it  was  observed 
that  the  senior  operator,  who  had  a  more  complex  page  selection  menu,  found  it  easier  to  slave  his  CRT  display  to  the 
junior  operator's,  than  to  find  his  way  about  the  display  selection  menu  tree.  The  complexity  of  such  systems,  adds  to 
the  operator's  workload  because  he  must  not  only  maintain  a  current  mental  model  of  his  operational  environment  and 
the  systems  he  is  controlling,  he  must  also  maintain  a  mental  model  of  where  he  is  in  the  multi-page  representation  of 
the  system  and  environment. 

Early  attempts  to  use  computers  in  Air  Traffic  Control  resulted  in  increased  workload  as  the  controllers  passed 
information  to  the  computer  by  "induced  tasks"  (18).  Similarly,  multi-function  controls  and  menus  can  increase  the 
work  required  to  input  information  by  a  series  of  selections,  de  Callies  and  Potter  (17)  report  the  case  in  which  the 
change  from  dedicated  controls  to  multi-function  controls  tripled  the  activity  required  to  initiate  a  simple  change  in 
radio  frequency.  Such  problems  need  not  occur  if  given  sufficient  attention  during  system  development.  In  one  project 
a  review  of  a  complicated  operational  ;;eq-encc  led  to  a  tenfold  reduction  in  the  number  of  individual  actions  required 
by  the  operator. 

Advanced  technology  has  an  impact  on  the  techniques  used  for  Workload  Analysis,  because  it  changes  the  tasks 
performed  by  the  operators  and  maintainers.  The  "classical”  aerospace  approach  to  workload  prediction  has  been  to 
calculate  it  from  the  ratio  of  time  required  to  perform  given  tasks  to  time  available.  Such  an  approach  works  for 
behaviouristic,  or  mechanistic  tasks  such  as  selecting  operational  modes  in  response  to  information  obtained  by  looking 
at  a  display.  It  is  more  difficult  to  apply  in  situations  where  the  operator's  tasks  have  a  high  cognitive  content,  or  where 
the  operator  is  task  sharing.  The  "timeline"  approach  to  workload  prediction  is  therefore  being  replaced  by  other 
developments,  several  of  which  are  baaed  on  the  concept  of  attentional  demand.  To  date,  however,  no  one  technique  has 
widespread  acceptance  outside  the  organization  which  originated  it. 

Performance  Specification 

Few  question  the  Importance  of  expressing  the  functional  requirement  of  a  system  in  clear  terms  of  effectiveness, 
but  this  seems  to  be  done  rarely.  It  does  not  appear  to  have  been  a  cleaily  Identifiable  stage  of  analysis  In  any  of  the 
projects  which  were  reviewed.  In  part  this  may  be  because  It  Is  difficult  to  show  the  Impact  of  human  performance,  or 
the  benefits  of  HE,  prior  to  actually  putting  a  system  Into  operation.  Advanced  technology  makes  such  predictions  even 
more  difficult,  because  It  changes  the  standards  of  acceptable  performance  of  systems,  for  example  the  sensitivity  of  sen¬ 
sors,  or  the  response  time  of  control  systems. 

Chapanis,  In  1901,  noted  that  the  familiar  measures  of  operator  performance  such  as  speed  and  error  do  not 
Impress  systems  designers,  particularly  when  compared  with  the  cost  and  value  estimates  available  from  other  speciali¬ 
ties  (10).  The  suggested  remedies  of  conducting  research  using  "systems  relevant*  criteria,  as  advocated  by  Melster,  for 
example  (20),  or  developing  Operations  Research  (OR)  techniques  which  Incorporate  human  performance  as  a  factor  In 
system  performance,  have  not  been  widely  used. 
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VVe  have  had  little  experience  of,  or  aucceas  with,  OR  type  mcMleh.  In  only  one  of  the  projects  reviewed  was  an  OR 
type  model  of  system  performance  used.  The  human  performance  characterized  by  the  model  made  the  usual  assump¬ 
tions  that  the  human  operator  is  completely  reliable,  is  linear,  stationary,  and  has  a  gain  of  1.  In  one  other  project  a 
contractor  did  attempt  to  use  a  model  of  human  detection  performance.  Unfortunately  the  model  was  used  to  show  that 
the  human  operator  would  improve  the  signal-to-noise  ratio  of  his  sensor  system  to  a  level  where  it  met  the 
specifications  set  for  hardware  performance,  independent  of  the  man-machine  interface.  Nevertheless  recent  develop¬ 
ments  in  operator  performance  modelling  appear  promising.  Network  modelling  tools  such  as  SAINT  promise  to 
improve  the  ease  of  development  of  such  models,  and  such  an  approach  is  being  used  to  predict  workload  in  the  most 
recent  project  reviewed. 

ENGINEERING  SPECIALITY  INTEXJRATION 

This  topic  covers  ’the  timely  and  appropriate  intermeshing  of  engineering  efforts  and  disciplines  such  as  ...  human 
factors  ...  to  ensure  their  infiuence  on  system  design*  (3).  Several  issues  which  modify  the  integration  of  human 
engineering  with  the  system  engineering  process  have  been  identified  in  the  foregoing  discussion.  These  include  the 
approach  taken  to  management  and  planning  of  the  HE  effort,  and  the  lack  of  standardization  in  the  use  of  available 
techniques.  The  main  thrust  of  the  remaining  discussion  is  to  identify  promising  solutions  to  some  of  those  problems. 

This  review  indicates  that  many  of  the  factors  which  hinder  the  integration  of  human  engineering  activities  with 
other  systems  development  activities  are,  in  large  part,  the  old  complaints  of  the  effort  being  too  little,  loo  late.  That 
this  is  still  a  problem  Is  disappointing,  because  human  performance  factors  have  become  much  more  critical  as  technol¬ 
ogy  has  advanced.  As  was  predicted  in  1050  (21),  the  task  of  improving  the  reliability  of  the  human  components  of  sys¬ 
tems  has  become  more  important  as  the  reliability  of  the  machine  components  has  improved;  and  as  predicted  in  1064 
(22),  the  role  of  the  human  operator  has  changed,  and  research  has  not  dealt  with  the  complexity  of  real  world  roles  and 
tasks. 


Organization  and  Procedures 

There  are  other  factors  which  mediate  the  success  of  HE  integration.  In  our  experience,  the  most  successful  organi¬ 
zational  means  of  Integrating  HE  with  SE  activities  was  the  Tactical  Crew  Compartment  Review  Committee  that  was 
formed  to  manage  HE  issues  in  the  CP-ldO  Aurora  project.  The  Committee’s  purpose  was  to  integrate  the  activities 
and  opinions  of  operators,  maintainers,  engineering  specialities,  and  human  engineers  working  on  different  aspects  of  the 
crew  compartment.  This  appears  to  be  the  the  function  envisaged  for  the  Human  Interface  Integration  Team  (HUT), 
which  was  recently  suggested  as  a  means  of  moving  HE  functions  away  from  a  reactive  ’wrist  slapping’  role  to  a  proac¬ 
tive  design  resource  (23). 

The  CP-HO  Committee  was  very  successful  as  a  forum  for  examining  and  reaching  consensus  on  any  issue  which 
impacted  the  operation  of  the  crew  compartment.  Much  of  the  success  of  the  committee  was  due  to  its  role  in  fostering 
communication  between  different  specialities:  our  experience  in  that  respect  supports  the  argument  (2)  that  SE  ’can 
only  be  accomplished  by  an  interdisciplinary  team,  and  the  first  and  moot  persistent  problem  of  such  a  team  is  effective 
communication”.  Contrasting  experience  was  provided  by  two  projects  where  the  HE  interests  were  split  up  between 
management,  operators,  vehicle  engineering,  reliability  and  maintainability,  and  life  support  equipment  specialists.  The 
result  was  an  ill-organized  approach  to  human  engineering  which  resulted  in  (sometimes  heated)  disagreements  among 
the  different  interests. 

A  HE  Co-ordination  Committee  is  also  able  to  facilitate  designing  for  operational  functionality.  By  this  is  meant 
that  Functional  Analysis  is  conducted  from  the  viewpoint  of  how  the  system  will  be  used,  rather  than  from  a  concern  of 
what  it  does.  As  this  review  has  shown,  the  advanced  man-machine  interface  is  often  dealt  with  "functionally”  by  pro¬ 
viding  for  each  role  and  task,  eg.  an  active  sensor  display,  a  passive  sensor  display  etc.  or  a  display  page  for  UHF  radio 
control,  another  for  VHF  etc.  But  that  approach  does  not  ensure  true  functionality,  because  the  way  the  operator  will 
use  the  equipment  over  time  has  not  been  analyzed  or  refined.  Indeed  our  experience  supports  the  finding  of  Graham 
(24)  that  many  designers  do  not  know  exactly  how  some  controls  and  displays  are  used  in  practice.  A  functional 
approach  which  emphasizes  how  the  system  will  be  used  couples  the  interaction  of  hardware,  software  and  human  func¬ 
tions,  and  leads  to  a  more  effective  integration  of  human  engineering  with  other  engineering  efforts.  To  do  this  requires 
an  attitude  that  HE  can  and  should  contribute  at  the  Function  Analysis  stage,  and  throughout  the  development  process, 
including  Task  Analysis  and  Workload  Analysis. 

Techniques 

If  HE  is  to  interact  effectively  with  other  engineering  specialities  early  in  systems  development,  more  effort  must  be 
scheduled  for  HE  analyses,  tests  and  experiments  to  explore  alternatives  at  the  Allocation  of  Functions  stage.  This 
should  include  exploration  of  potential  operator  capabilities,  and  more  detailed  investigations  of  what  operators  can  and 
cannot  do  with  existing  systems.  In  this  context  it  seems  unavoidable  that  more  use  must  be  made  Of  man-in-the-loop 
simulation.  Recent  advanced  aircraft  projects  in  the  USA  and  Europe  have  employed  such  simulation,  but  not  all  pro¬ 
jects  do  so.  Man-in-the-loop  simulation  is  very  expensive  and  time-consuming,  and  cannot  be  expected  in  all  projects. 
Only  one  of  the  projects  we  reviewed  made  extensive  use  of  it  as  a  development  tool.  One  possible  solution  to  the  prob¬ 
lem  of  costs  is  to  arrange  for  any  Systems  Integration  F'acility,  or  Laboratory  to  support  man-in-the-loop  experimenta¬ 
tion. 

An  increase  in  the  in  the  use  of  experimentation  must  be  matched  by  an  increase  In  the  use  of  performance  stan¬ 
dards.  It  will  also  require  improvements  in  performance  measurement  techniques  within  the  context  of  systems  opera¬ 
tion.  The  author  has  personal  experience  of  the  benefits  of  using  the  system  Parameters  Document  (26)  as  a  means  of 
specifying  the  human  operator  performance  characteristics  of  a  new  system.  It  worked  well,  but  the  majority  of  entries 
proved  to  be  design  standards  rslher  than  performance  standards,  because  no  effort  had  been  scheduled  to  derive  opera¬ 
tor  pc.-formuiice  standards  for  the  system.  The  move  to  such  ’Parametric  Documentation”  which  started  in  the  I080s 
does  not  seem  to  have  been  followed  up,  or  fully  exploited,  although  more  recently  the  US  Army  has  argued  that  there 
should  be  a  shift  from  design  speclflcallon  to  apecllIcBtlon  for  performance  In  Human  Engineering  (29).  The  use  of  OR 
type  models  which  incorporate  human  operator  performance  Is  seen  as  a  promising  approach  to  Identifying  the  aspects 
of  operator  performance  which  are  critical  to  system  effectiveness. 
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A  consist«Dt  theme  of  this  paper  has  been  that  available  HE  techniques  are  not  being  used.  Thb  agrees  with  a  pre¬ 
viously  reported  conclusion  that  the  basic  problem  is  not  one  of  lack  of  HE  data  or  principles,  but  a  lack  of  attention  to 
their  application  (t).  It  is  also  apparent  that  there  b  a  need  to  develop  improved  techniques.  In  10S7  Singleton,  Eas- 
terby  and  Whitfield  (27)  argued  that  the  increase  in  scale  and  complexity  of  systems  required  an  equal  advance  in  HE 
approach  and  techniques,  and  that  the  most  glaring  gap  in  current  expertbe  was  In  the  area  of  Task  Analysis.  In  1081 
Topmiller  (28)  indicated  that  a  range  of  techniques  had  been  developed,  many  of  them  related  to  Operations  Research, 
but  that  comparatively  little  use  was  being  made  of  them.  He  argued  for  more  eflbrt  to  be  devote^  to  technology 
transfer  from  the  developers  to  the  potential  users.  In  1084  the  NATO  Workshop  on  Systems  Ergonomics  concluded 
that  many  techniques  were  not  "user  friendly*  and  not  easily  transferred  outside  the  laboratory  wlcre  they  were 
developed. 

Standardization  of  available  HE  techniques  applicable  to  systems  development  would  facilitate  their  understanding 
and  use  by  other  engineering  specialities.  An  initiative  to  do  so  was  started  within  NATO  MAS  Aircraft  Instruments 
Panel,  in  1088,  and  such  standardization  b  one  of  the  aims  of  the  recently  formed  NATO  DRG  Panel  VIII  Research 
Study  Group  on  Human  Engineering  Analysb  Techniques.  The  recommendation  of  the  1984  NATO  DRG  Workshop  on 
Systems  Ergonomics,  that  a  NATO  Clearinghouse  be  estabibhed  to  evaluate,  standardize,  certify,  and  make  available 
human  fz  jts  techniques,  methodologies  and  findings,  together  with  their  documented  applicability,  generalizability  and 
merit  has  yet  to  be  acted  upon. 

CONCLUSION 

One  premise  of  thb  conference  was  that  the  typical  approach  to  design  may  not  be  appropriate  for  the  develop¬ 
ment  of  advanced,  highly  integrated  avionics.  Thb  review  has  shown  that  advanced  technology  exacerbates  many  of 
the  problems  associated  with  the  application  of  Human  Engineering  to  systems  development.  It  b  concluded  that  these 
problems  have  their  basis  primarily  in  management  issues,  such  as  the  attitude  to  HE,  organization  and  staffing  of  the 
IIE  effort,  and,  perhaps  most  importantly,  planning  and  scheduling  that  effort.  It  b  also  concluded  that  the  approach 
that  should  be  followed  to  improve  the  application  of  HE  in  advanced  development  projeeb  b  directly  compatible  with 
the  recommended  approach  to  Systems  Engineering. 

A  variety  of  procedural  solutions  have  been  discussed.  Perhaps  the  most  important  b  that  a  Human  Engineering 
Plan  should  ^  prepared  at  the  outset  of  any  developmental  project,  and  that  a  coordinating  committee  with  representa¬ 
tion  from  operators,  engineering  specialities,  and  human  engineering,  b  one  of  the  most  effective  ways  of  achieving  the 
integration  of  the  different  interests.  It  b  abo  suggested  that  rn  approach  to  functionality  which  emphasizes  how  the 
system  will  be  used  on  a  temporal,  or  mission  segment  basb,  can  integrate  not  only  the  various  Human  Factors  activi¬ 
ties,  but  all  engineering  speciality  efforts. 

Finally  it  b  concluded  that  some  currently  available  toob  and  techniques  can  contribute  to  the  successful  applica¬ 
tion  of  HE.  Chief  of  these  b  a  properly  conducted  Task  Analysb  based  on  a  realbtic  Mission  Analysb.  Two  techniques 
which  appear  prombing  are  the  use  of  OR  type  modeb  and  man-in-the-loop  simulation,  to  investigate  the  impact  of 
operator  performance  on  system  performance.  Neither  technique  appean  to  be  widely  used,  however.  It  b  suggested 
that  man-in-the-loop  simulation  would  be  fostered  if  the  Systems  Integration  Facilities,  of  Laboratories,  which  are  being 
used  increasingly  in  advanced  projects,  are  designed  to  support  HE  tests  and  simulations.  It  b  also  concluded  that  there 
is  a  need  for  standardization  of  the  techniques  which  are  used  to  apply  human  engineering  at  all  stages  of  project 
development. 
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LE  TEST  DE  LOGICIEUS  AVIONIQUES  COMPLEXES  : 


UKE  experience  PRATIQUE 


H.  MUENlER 

ELECTRONIQUE  serge  DASSAULT 
922 U  SAINT-CLOUO  -  FRANCE 


RESUME  :  Cec  expose  presence  lee  techniques  utlltsees  i  I'Electronlque  Serge  DASSAULT  pour  le  test  de  logi- 
clels  avlonlques,  prlncipalement  des  loglclels  esbarques  utilises  i  bord  des  avlons  MIRAGE  FL  et 
MIRAGE  2000. 

Les  exigences  de  surety  de  fonctlonnement  qui  s'attachent  d  de  tels  loglclels  imposenc  des  contrS- 
les  rlgoureux  I  cous  Les  scades  de  diveloppement  et  partlculldrenent  d  celui  du  test.  Elies  ont 
aussi  aoene  i  concevolr  et  1  utlllser  des  aethodes  et  des  outils,  dans  une  approche  globale  du  cy¬ 
cle  de  vie  du  Iogteiel< 

C'esc  pourquol  I'accent  sera  mis  sur  I'lmpact  que  peut  avoir  sur  le  test  I’actuelle  Evolution  des 
o£thodes  de  specifications,  et  1' Integration  cfolssante  des  outils. 


INTRODUCTION 


Les  applications  avlonlques,  et  de  faqon  plus  generale  les  applications  eobarquees,  $e  caracterl- 
sent  par  un  certain  nonbre  de  proprietes  telles  que  leut  longue  duree  de  vie  ec  des  contralntes  severes  en 
volume  et  en  polds. 

Un  certain  nombre  de  facteurs,  propres  d  ces  applications,  ont  un  Impact  partlculierement  Impor¬ 
tant  sur  les  actlvues  de  test.  C'est,  en  premier  lieu,  le  haut  niveau  de  sQret§  de  fonctlonnement  requls 
qul,  I  lul  seul,  Justlfle  la  part  imporiante  prise  par  lea  tests  dans  le  processus  de  d^veloppement 
(de  ^  a  50%).  C'esc,  ensulte,  I'aspect  ’'embarqu^**  qui,  de  par  la  sp^clflcitl  des  calculateurs  clbles  et  de 
leurs  entr^es-sorcles,  conduit  i  des  developpements  **cr0l8€s**  et  Impose,  pour  les  tests  men^s  sur  calcula- 
ceurs  clbles,  de  slmuler  I'envlronneraenc  opf ratlonnel.  C'eat,  dans  le  mSme  ordre  d'id^es,  I'aspect 
"temps-rSel"  qul  exprlrae  robllgatlon  dans  laquelle  le  loglclel  se  trouve  de  reaglr  rapldement  3  des  evfene- 
ments  exterieurs*  Cette  caracterlstlque  "temps-reel"  impose,  au  niveau  du  test,  une  reproduction  aussl  fi¬ 
ddle  que  possible  des  aspects  temporels  tant  de  I’envlronneoent  que  du  comportement  du  loglclel  lul-mdme 
(execution  du  loglclel  reel  non  Instrumentd). 

D'autres  facteurs,  moins  spdclflques,  ont  egalement  un  impact  Important  sur  le  test  de  loglclels 
avlonlques  :  ce  sont,  par  exemple,  le  taux  dlevd  de  modifications  (tests  de  non  regression)  et  le  souci  de 
producclvltd  (tests  symbollques) . 

Tous  ces  facteurs  font  du  test  des  loglclels  avlonlques  une  operation  difficile  et  couteuse,  pour 
laquelle  peu  d'ouClls  dcalent  encore  dlsponlbles  11  y  a  quelques  anndes.  On  a  pu  dire  ainsl  que  les  appli¬ 
cations  teaps-rdel  conscitualent  Le  'Monde  Perdu'  du  test  et  de  la  mise  au  point  de  loglclel  (Robert  L. 
GLASS,  Boeing  Aerospace  Company). 

Nous  prdsentons  IcL  les  solutions  qul,  d  I'Electronlque  Serge  DASSAULT  (ESD),  ont  etS  apportdes  d 
ces  probldmes  depuls  plusleurs  anndes. 


CHAPITRE  I  :  L*EXPERIRNCt:  DE  L’ESD 


L'ESn  est  speclallsee  dans  I'etude,  le  developpement  ec  la  fabrication  de  oaterlels  electruniques 
dans  les  domalnes  civile  et  lallitalres. 

L'effectlf  de  I'ESD  esc  acCuellentenc  de  4000  personnes,  done  plus  de  2000  Inginleurs  et  cadres.  Le 
chlffre  d'affaires  19d5  s'^levaic  a  plus  de  3000  i4F  (un  tiers  environ  etanc  realise  a  I'exportatlon  et  un 
quart  dans  xe  domalne  de  I’ Inforoatlque  aerospatlale)* 


L'RSD  eat  fournisseur  de  nombreux  equlpeinencs  des  avions  MIRAGF.  FI  et  !ilRAGE  2000  d’Avlons  Itarcel 
DASSAULT~Breguet  Aviation  (AMD-BA)  pour  lesquels  elLe  a  developpe  plusleurs  gammes  de  calculateurs  embar- 
ques  unlveraels  (calculateurs  M182  pour  le  MIRAGE  FI  et  serle  84  pour  les  MIRAGE  2000).  ESD  fournit  &gale* 
ment  le  systSme  de  transmission  d' Informac Ions  numerlques  DIGIBUS  qul  esc  normalise  en  FRANCE  pour  les 
trots  Armea  (noriae  GAM-T-101  ).L*ESD  developpe  egalenent  depuls  1977  les  logictels  operatlonnels  fonctlon- 
nant  sur  ces  calculateurs  alnsl  que  les  Loglciels  de  production  et  de  test  assocl&s.  Elle  s'est  dotee, 
pour  rSpondre  \  ces  besolns,  d' importances  equlpes  loglclel  (plus  de  200  personnes). 

Plus  de  20  millions  d'oetets  de  loglciels  op^racionnels  one  §t§  alnsl  livres  sur  un  ensemble  de 
qulnze  proJets.  Pour  chaque  projet,  une  llvralson  esc  effectu&e  environ  coos  les  mots  ;  elle  conporte  en 
moyenne  600  000  octets  de  code,  60  000  pages  de  listings  et  10  000  pages  da  documents. 

Ces  loglciels  gone  i  90%  ecrlts  en  LTR,  un  langage  haut  niveau  temps-r6el  derive  d'ALGOL.  LTR  fut 
' ' des  premiers  langages  de  ce  type  1  utilise  pour  des  applications  avlonlques  pulsqu'll  a  ete  mis 

en  service  I  I'Electronlque  Serge  DASSAULT  en  1977.  Les  10%  de  loglclel  restant  correspondent  i  des  sec¬ 
tions  critiques  en  temps  de  calcul  et  sonc  ecrlts  en  langage  d'assemblage.  Tres  blencEc  I'ESD  disposers 
£galement,  pour  ses  calculateurs,  d'ouclls  de  programmation  en  Ada. 

II  fauC  soullgner  I'effort  Important  encrepcis  par  depuls  10  ans  dans  le  domalne  du  genie 

loglclel  qul  s'est  tradulc,  d'une  part  par  la  definition  et  La  mlse  en  application  de  la  methodologle 
MINERVE  (1),  d'aucre  part  par  La  realisation  d'oucils,  prlnclpalement  d’alde  a  la  specification  (DLAO  (2)) 
et  au  test  (BVL  (3),  IDAS  (4)).  Le  paragraphe  suivanc  presence  succlnctement  la  methodologle  MINERVE. 


(1)  MINERVE  :  ^thodologie  INdustrtelle  pour  I'^tude,  la  Realisation  et  la  Validation  de  loglclel 

d'Equlpement 

eat  une  oiarque  deposee  de  I'Electronlque  Serge  DASSAULT. 

(2)  DLAO  ;  Reflnltton  de  Loglclel  Asslstee  par  Rrdtnateur 

est  une  marque  deposee  de  I'Electronlque  Serge  DASSAULT. 

(3)  BVL  :  Bale  de  Validation  de  Loglclel. 

:  information  de  la  Detection  d’Rnomalles  dans  les  R^stemes 
esc  une  marque  deposee  de  I'Electronlque  Serge  DASSAULT. 


(4)  IDAS 
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CHAPITRE  2  :  LA  METHODOLQGIE  ;  MINERVE 


La  aichodologle  MINEKVE  a  d£jd  fait  I'objec  d'une  preaentatlon  dans  le  cadre  d'un  symposium  AGARD 
(J.  PERIN  :  LOGICIEL  AVIONIQUE  :  EXPERIENCES  PRATIQUES  D'UNE  METNODOLOGIE  -  AGARD  Conference  Proceedings 
272  -  1979).  Nous  rappelons  id  aes  Elimenca  principaux. 

MINERVE  a  pour  objecclfa  de  faclilter  la  production  d'un  logiclel  de  quailed  dans  des  conditions 
de  coQts  et  de  delala  maltrlsablest 

La  quality  d'un  logiclel  se  d£finlt  non  seuleaent  par  sa  conformity  aux  spycif Ications  mals  aussi 
par  sa  facility  d'evolutlon,  sa  clarty,  la  prycislon  de  sa  documentation,  sa  surete  de  fonctlonnement , 
ses  performances,  etc. 

La  maltrlse  des  couts  et  des  dyials  ryalde  dans  la  possibility  d'entreprendre  S  tout  moment  des 
actions  Cendant  au  respect  des  engagements.  Elle  s'obtient  par  la  connaissance  permanence  de  I'avancemenc 
du  projec  et  des  travaux  restant  k  effectuer. 

Pour  atteindre  les  objectlfs  prycydents,  MINERVE,  piece  maltresse  de  I'assurance  et  du  contrSle- 
quallte  logiclel  au  aeln  de  I'ESD,  s'appule  sur  crois  prloclpes  : 

**  les  projets  sonc  dycoupys  en  phases  et  en  ycapes  caraccyrlsyes  par  des  actlvlcys,  des  produits 
et  des  responsabillces  clairement  definla. 

-  la  quality  des  produits  ainsi  que  leurs  couts  et  delala  de  ryallsatlon  sont  controiys  de  fa^on 
continue. 

“  les  modifications  sont  prises  en  compte  quel  que  soit  le  degry  d'avancement  des  travaux,  selon 
une  procydure  unique  deatlnye  a  eviter  toute  dygradation  de  la  quality  du  logiclel. 

2.1.  Principe  du  dycoupage  dee  projets 

Les  projets  sont  decoupys  chronologiquement  k  deux  nlveaux  (lea  phases  et  les  ytapes)  selon  le 
schema  sulvant  : 

PHASE  1.  DEFINITION 

Ecape  l.l  :  nyfinitlon  globale  du  syscdme 
Scape  1.2  ;  i>«.'inicl'‘ '  <v‘'raClonnelle  du  logiclel 
Ecape  1.3  :  oyfinlcion  fonctlonnelle  du  logiclel 

PHASE  2.  PLANIFICATION 

Ecape  2.L  :  Concrdle  de  la  falsabilicy  technique 
Ecape  2.2  :  Dyflnlcton  des  moyens  cechnlques, 

Ecape  2.3  :  Ryexamen  du  plao'-qualicy  logiclel 
Ecape  2.4  •  Ryexamen  des  plannings  et  des  coGts 

PHASE  3.  REALISATION 

Etape  3.1  :  Concepcion  globale 
Ecape  3.2  ;  Concepcion  decailiye 
Etape  3.3  :  Codage  et  tests  unitalres 
Etape  3.4  j  Tests  d* intygration 
Etape  3.S  :  Tests  fonctlonnels 
Ecape  3.6  :  Validation  du  logiclel 

PHASE  4.  EXPLOITATION 


Ecape  4.1  :  Integration  du  systyme 
Etape  4.2  :  Suivl  du  logiclel 
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Les  etapes  I • 1 • 
d'armes  (AHD-BA),  toutes 


1.2  et  la  phaae  4  televent 
les  autres  etapes  relevent 


de  la  responsabillt^  du 
«Je  celle  du  reallsaLeur 


naltre  d’oeuvre  du  sysc^me 
du  loglctei  (ESD). 


Les  ETAPES  aont  caracterlsees  par  la  nature  de  I'ACTIVITE  PRINCIPALE  'i*j1  y  eat  exercee.  Celle-cl 
se  concretise  toujoura  par  un  uu  plusleurs  produlta  foriaalises  ou  PRODUITS  KINERVE  :  documents,  cassettes, 
bandes  magnetiques,  etc.  Une  activity  princlpale  termln^e,  sea  produlta  ne  peuvent  etre  modifies  que  par 
une  procedure  partlcull&re  (cf.  paragraphe  2.3). 


Principe  des  contr61es 


Les  concroles  s'exercent,  tout  au  long  du  projet,  a  deux  nlveaux  ; 


-  qualite  des  prodults  (programmes  et  documents), 

-  coQts  et  delals. 


Tout  contrSle  de  qualite  s'effectue  sur  un  prodult  MINERVE. 
Ces  contrdles  sont  de  trots  types  : 

-  Cont roles  de  type  A  : 


Ce  sont  des  contrdles  Internes  au  prodult  d*une  etape.  lls  consistent  A  verifier  que  le  prodult 
de  I'dtape  respecte  les  rdgles  ap&clflques  (pr^clslea  dans  Le  plan-quallte  loglciel)  et  les 
standards  generaux  (d^finls  dans  le  aanuel'^quallt^  loglciel)  qul  lul  sont  appllcables. 

-  Cont roles  de  type  B  : 


Ce  sont  des  contrdles  de  coherence  entre  les  prodults  d'une  etape  et  ceux  des  etapes  anterleu- 
res.  Ce  type  de  contrdle,  cooue  le  precedent,  esc  realist  sous  forme  de  relectures  de  documents 
et  de  revues  de  projet. 

-  Contrdles  de  type  C  : 


Ce  sont  les  tests  des  programmes,  lls  se  deroulent  en  quatre  Stapes  successives  ec  s'effectuent 
P'^ur  cha'‘”''<‘  -'•.'nT*'  ;Ve5  selon  des  points  de  vue  et  par  reference  A  des  documents  dlff^rents. 
Alnsl  les  tests  realises  au  cours  des  etapes  de  codage  et  tests  unltalres  (3.3),  tests 
d’ Integration  (3.4),  tests  fonctlonnels  (3.5)  et  validation  do  loglciel  (3.6)  permectent  de  ve¬ 
rifier  La  conformite  des  programmes  A  leurs  descriptions  successives  Stabiles  au  cours  dea  Ita- 
pes  symetrlques  :  conception  detainee  (3.2),  conception  globale  (3.1),  definition  fonctlonnelle 
(1.3)  ec  definition  operatlonnelle  (1.2). 

La  figure  I  schematise  ces  contrdles. 


manuel-quallte  et  plan-quallte 
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2.2.2.  ContrSle  des  couts  et  dea  delals 

Ce  contr51e  s'effeccue  d  Intervalies  rapproch^s  pendant  Coute  la  durge  du  projet.  T1  consiste  a 
aesurer  le  degr4  d'avanceaeot  des  travaux  en  couts  et  delals,  puls  3  le  comparer  aux  previsions  consignees 
dans  un  document  de  reference. 

2.3.  Principe  des  modifications 

La  prise  en  compte  d'une  modification  peut  Intervenlr  quel  que  solt  le  degrfe  d'avancement  du  pro- 

jet. 

^ucun  prodult  MINERVE  ne  peut  Stre  aodlfie  en  dehors  de  la  procedure  decrlte  cl-dessous,  indispen¬ 
sable  pour  conserver  la  coherence  des  dlff£rents  prodults  pendant  toute  la  vie  du  loglclel. 

-  Prise  en  compte  de  la  modification  : 


Aprds  determination  du  prodult  MINERVE  i  modifier  sltu^  le  plus  en  amont  dans  le  processus  de 
dlveloppeaent  du  loglclel,  une  FICHE  DE  HODXPtCATION  de  ce  prodult  est  redlgSe  par  le  demandeur 
si  elle  concerne  le»^  prodults  de  L'^tape  1.2,  ou  par  le  reallsateur  si  elle  concerne  les  pro- 
dults  d'une  etape  ulterleure. 

~  Realisation  de  la  modification  : 


La  modification  alnsi  prise  en  compte  conduit  i  la  reprise  de  routes  les  etapes  dont  les  pro~ 
duits  sont  remls  en  cause,  en  commenqant  par  la  plus  en  anont  de  celles-cl. 

L'execuclon  des  modifications  induitea  dans  les  dlfferents  prodults  concernes  est  consignee  sur 
une  PICHE  SUIVEUSE,  elaboree  d^s  la  decision  de  realisation. 
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CHAPITRE  3  :  LBS  TESTS  DE  LOCICIEL 


Coaoe  11  a  vu  dans  le  chapltre  precedent,  le  test  du  loglciel  Intervienc  dans  les  Stapes  3.3 
I  3>6  du  cycle  de  vie.  A  I'lssue  de  ces  Stapes,  le  loglciel,  valldS  sur  son  materiel,  est  remis  au  raaltre 
d'oeuvre  du  systSme  d'arnes  qul  procSde  aloes  a  I'integratlon  du  syscSme  (Stape  4.1).  Ce  chapltre  ne  tralce 
que  des  tests  de  loglciel  propreoent  dlts. 

Lots  des  Stapes  1.2  S  3.2,  le  systSne  a  StS  dScooposS  a  dlfferents  nlveaux  (fonctlons  operatfon- 
nelles,  fonctlons  loglcielles,  modules,  plSces,  etc..). 

A  cheque  Stape,  les  tests  portent  done  suf  le  niveau  de  decomposition  dScrlt  dans  I'etape 
''symStrlque*'  (ct.  fl6..re  1)  selon  un  processus  de  recomposition  progressive  du  loglciel  en  "blocs"  dt.  call- 
le  crolssante.  Cette  approche  prSsente  I'avantage  de  faclllter  S  tous  les  stades  la  simulation  de 
1 ' envl ronnement . 

Au  fur  et  a  mesure  que  des  ensembles  plus  Importants  de  loglciel  sont  cestSs,  l‘exploslon  comblna- 
tolre  conduit  1  abandonner  le  test  d* Informations  Internes  aux  programmes  {telles  que  les  cherains  de 
controle)  au  profit  de  tests  fonctlonnels  qul  devlennenc  plus  stgnlf Icatlfs.  Les  techniques  de  test  corres- 
pondantes  sont  habituellement  designees  par  les  termes  de  test  "bolte  blanche"  et  test  "bolte  noire". 

Cecl  est  resume  par  la  figure  2  : 


ETAPE 

TEST  BOITE  BLANCHE 

TEST  BOITE  NOIRE 

3.3. 

Tests  Unltalres 

Tests  de  branches 

Tests  de  chemlns 

Teats  externes  de 
places 

3.4. 

Tests  staclques 
d' Integration 

Tests  de  branches 

Testa  d'inierfaces 
entre  plices 

Tests  externes  de 
modu Les 

Tests  dynamtques 
d* Integration 

Tests  d'lnterfaces 
et  de  synchroni¬ 
sation  entre 
processus 

3.5. 

Tests 

fonctlonnels 

Tests  externes  de 
fonctlons  logl- 
cielles 

3.6. 

Validation 

Tests  externes  de 
fonctlons  op§ra- 
tlonnelles 

figure  2 


II  faut  soullgner  que  I’actlvltS  de  test  est  associ^e  i  une  actlvlte  de  raise  au  point.  Cette  der- 
niere  vise  d  localtser  I'origlne  des  erreurs  d^tectees  par  le  test  et  n^cesslte,  quel  que  soLt  le  niveau, 
I'exploltatlon  d' informations  internes  au  programme  (approche  de  type  "bolte  blanche"). 

Les  techniques  et  les  outlls  de  test  utilises  pour  chaque  etape  (de  la  responsablllte  du  reallsa- 
teur  de  loglciel)  sont  pr^sentes  dans  les  paragraphes  sulvants. 


3.1.  Les  tests  unltalres 


Le  niveau  de  dScooposltlon  concerne  est  la  "plJce"  dont  les  caract^rlst Iques  sont  d'etre  d'un  vo¬ 
lume  reduit  (inf^rleur  i  100  Instructions),  de  correspondre  i  une  structure  du  langage  de  programmatlon 
possSdant  un  seul  point  d'entree  et  un  seul  point  de  sortie  (par  example  procedure)  et  d'etre  une  unltl 
de  compilation  et  d'archlvage. 

T  'objectlf  principal  des  tests  unltalres  es*  de  verifier  que  la  logtque  de  controle  des  places  est 
conforme  3  la  definition  qul  en  a  ete  falte  lors  de  I'Stape  de  conception  dltalllee,  et  qul  est  consignee 
dans  le  DOSSIER  DE  CONCEPTION  DETAILLEE  DU  LOGICIBL,  produit  MINERVE  de  :ette  etape. 

Trols  types  de  tests  doivent  Stre  effectues  sur  les  places  (cf.  figure  2)  : 

-  Tests  de  branche  : 


Les  Jeux  de  tests  doivent  Stre  elabores  afln  de  provoquer  l'ex§cutlon  au  molns  une  fols  de  cha- 
cune  des  branches  de  la  pldce,  en  s'assurant  apr^s  execution  que  I'etat  de  la  pl3ce  3  la  sortie 
de  la  branche  est  blen  celui  attendu. 
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-  Tests  de  chemln  : 


Un  cheialn  est  on  ensemble  de  branches  reliant  logiquement  le  point  d'entree  d’une  pldce  ^  son 
point  de  sortie.  Les  Jeux  de  tests  dolvent  permettre  de  parcourlr  chacnn  des  chemins  de  la  pl^ce 
en  s'assurant  1  I'lssue  du  parcours  que  la  ptdce  est  blen  dans  I'etat  attendu. 

-  Tests  externes  de  pl^ce  : 


II  s'aglt  de  s'asaurer  que  la  pldce  acconplit  blen  la  fonctlon  (ou  les  fonctions)  prevue(s).  Le 
jeu  de  tests  dolt  comporter  en  entree  des  donates  coh^rentes  et  ayant  one  signlf tcatlon  fonc- 
tlonnelle. 

La  mise  en  oeuvre  de  ces  tests  est  decrlte,  lors  de  la  phase  de  conception  detaillie,  sous  forme 
de  flches  de  tests  unltalres. 

Ces  flches  contlennent  trols  types  d* Informations  : 

-  les  donates  d'entree, 

-  les  conslgnes  de  nlse  en  oeuvre  (lancement  et  trace), 

I'Stat  attendu  apris  execution. 

Lors  de  I'etape  de  tests  unltalres,  ces  flches  sont  tradulces  sous  forme  de  programme  de  tests 
executes  par  I'outll  IDAS  (cf.  Chapltre  un  programme  etant  assocLe  k  chaque  pldce. 

Pour  effectuer  ces  dlffSrencs  types  de  tests,  11  peut  %tre  nScessalre  de  slmuler  I'environnement 
de  la  piece,  solt  par  des  places  d^Ja  tesc^ea,  solt  par  des  places  speclalement  ecrltes  i  cet  effet. 


Les  volumes  memolre  et  Les  temps  d'exicutlon  sont  egaletnent  conserves  afln  de  maltrlser  ces  para- 
m^tres  au  cours  du  processus  d* Integration. 

A  I'lssue  de  ces  operations,  les  produits  MINERVE  elabores  sont  : 

-  les  PIECES  DE  CODE  sauvegardees  sous  forme  de  code  source  et  de  code  objet, 

-  les  LISTINGS  de  ces  places, 

-  le  DOSSIER  DE  CRKTIFlCATIf)N  DES  PIECES  constitue  des  flches  de  tests  unltalres  renselgn&es  lors 
de  I'exScuclon  de  ceux-cl. 


3.2 .  Lea  rests  d' integration 

Le  niveau  de  dScotoposlclon  concern^  peut  §tre  le  processus  ou  le  module. 

un  processus  correspond  i  L'ensemble  des  traltemencs  done  I’executlon  est  subordonn&e  d  la  meme 
condition  d'acclvacton  (IvSneoenc  excecne  ou  Interne,  friquence). 

Un  module  est  une  partle  de  processus  poss^dant  une  coherence  fonctionnelle,  c'est-l'dlre  apparte- 
nant  3  une  raSme  fonctlon  loglclelle  (cf.  paragraphe  3.3.).  Un  module  est  constltufe  d'une  partle  interface 
qui  contlent  les  informations  visibles  de  L'ext§rieur  ainst  que  les  directives  d' inportat Ion  de  donn§e5  de 
I'ext^rleur  et  d'un  corps  comporcant  des  donnees  locales  et  une  sequence  d'appels  de  places.  Les  langages 
de  programmatton  les  plus  recents  (LTR3,  Ada)  permettent  malntenant  de  repr§<>«nr''*r  trds  slmplereent  les 
structures  de  processus  et  de  module. 

L'objectlf  principal  des  tests  d' Integrat ton  est  la  vlrlflcatlon  des  Interfaces  entre  les  conscl- 
tuants  (places,  modules,  processus)  du  loglctel,  vis  3  vis  du  DOCUMENT  DE  CONCEPTION  GLOBALE  DU  LOGICIEL 
(prodult  MINERVE  de  I’etape  de  conception  globale). 

Les  tests  qui  sont  conduits  3  cet  effet  sont  de  deux  types  : 

-  Les  tests  d* INTEGRATION  STATIQUE  :  les  Interfaces  entre  pieces  et  entre  modules,  3  I'lnterleur 
de  chaque  processus,  sont  verlflSes  Independaoment  des  contratntes  'temps  r§el'. 

-  Les  tests  d' INTEGRATION  DYNAMIQUE  :  les  dlfferentes  conditions  d'actlvatlon  sont  mlses  en  oeuvre 
afln  de  verifier  Les  Interfaces  entre  les  processus  et  I’environnement  extlrleur  d’une  part  et 
..litre  les  processus  eux-’mSmes  d'autre  part.  C«s  tests  s’exercent,  en  partlculler,  sur  le  partage 
du  temps  (durSe  des  cycles,  synchronisation,...)  et  deo  doiuuies  (coherence,  acc3s  aux  variables 
partagges, . . . ) . 

Un  premier  travail  constate  en  la  redaction  du  DOSSIER  DES  TESTS  D' INTEGRATION  DU  LOGICIEL. 
Celul-'cl  se  presents  sous  la  forme  de  FICHES  DE  TESTS  STATIQUES  de  modules  et  de  processus  ainst  que  de 
FICHES  DE  TESTS  DYNAJII^UES  de  processus. 

La  formalisation  de  ces  tests  s'effectue  ensutte  de  fa9on  analogue  3  celle  des  tests  unltalres 
par  ecrlture  et  archlvage  de  programmes  de  test  3  I'aide  de  I'outll  IDAS.  Deux  outlls  suppl^mentatres  sont 
utilises. 
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.  COCOOIN  (1),  pour  le  contrdle  du  passage  des  param£tres»  car  la  version  du  langage  LTR  uclllsee 
acCuclIement  ne  dispose  pas  de  la  conpilation  sSparee  (cet  outll  ne  sera  plus  nScessalre  pour 
les  progranunes  Merits  dans  la  dernidre  version  du  langage  (LTR3)  ou  en  Ada).  Cet  outll  recherche 
I'ensemble  des  procedures  appelees  par  un  nodule  et  les  Insire  dans  le  flot  de  compilation  de 
celul-cl.  Le  controle  est  alors  effectu4  par  le  compllateur  LTR. 

.  RDL  (2)  pour  le  contrdle  des  entrees-sortles  de  I'^qulpemenc  lorsque  le  module  ou  le  processus 
teste  emec  des  Informations  sur  celles-ct.  EDL  permet  I'observation  et  I'enreglstrement  des  mes-' 
sages  Imls  sur  un  bus  raulctplexe  de  type  DICIBUS  ec  le  controle  a  posteriori  des  contralntes  de 
temps  et  d' ordonnancement  Imposees  i  ces  messages. 

Les  prodults  MIN8KVE  de  cette  ^tape  sonc  : 

-  le  DOSSIER  DES  TESTS  D' INTEGRATION  DU  LOGICIEL, 

-  un  PROGRAMME  sauvegarde  sous  forme  de  code  objet  et  conforme  au  document  de  conception  globale, 

-  le  DOSSIER  DE  CERTIFICATION  DES  MODULES  ET  DES  PROCESSUS  constUue  des  fiches  de  tests  statiques 
et  dynamlques  renselgnies  lors  de  I’executlon  de  ceux-cl. 


1.3.  Lea  teats  fonctlonnels 

L*objectlf  de  cette  etape  est  de  verifier  la  conforralce  du  programme,  produtr  de  I'etape  preceden- 
te,  au  document  de  SPECIFICATIONS  PONCTIONNELI.ES  DU  LOGICIEL  (prodult  MINERVE  de  I'etape  de  definition 
fonct lonnelle  du  loglclel). 

Ce  travail  s'effectue  en  deux  temps  : 

~  tout  d'abord,  le  DOSSIER  DES  TESTS  DES  FONCTIONS  LOCICIELLES  est  redige.  Ce  dossier  comprend, 
pour  chaque  llvralson  de  programme,  un  ensemble  de  tests  clatreiaent  IdontIfle.  Ces  tests  sont 
regroupes  par  "fonctlons  ioglclelles" . 

Les  Coactions  Ioglclelles  sont  lea  fonctlons  du  calculateur  vues  sous  I’angle  du  reallsateur  du 
loglclel  de  i’lqulpenient. 

Elies  sont  constlcu^ea  par  des  regroupements  de  cralteraents  selon  des  entires  fonctlonnels  pro- 
pres  au  rSalisaceur.  Les  crltdres  de  regroupemenc  peuvent  Stre  : 

.  la  faclLltS  d' apprlhenslon  du  loglclel, 

.  la  facility  d'evolutlon, 

.  la  facility  d' organisation  du  loglclel, 

.  la  r4utUlsablLlt§. 


Chaque  test  comprend  : 

.  la  sequence  des  actions  nScessalres  a  son  execution,  d^crltes  d’un  double  point  de  vue  fonc- 
ttonnel  et  de  mlse  en  oeuvre.  Le  point  de  vue  fonctlonnel  permet  d’effectuer  la  correlation 
des  tests  avec  les  specifications  fonctlonnelles.  La  description  de  la  mlse  en  oeuvre  est  ba- 
s4e  sur  les  outlls  utilises  :  prlnclpaleaent  la  BVL  (voir  Chapltre  4)  qul  realise  la  simula¬ 
tion  de  I'envlronnement  de  l*4qulpement  et  permet  d’observer  son  comportement  au  travers  des 
liaisons  operatlonnelles  (test  botce  noire)  et  IDAS  (voir  Chapltre  6)  qul  permet  d'effectuer 
la  mlse  au  point  en  observant  le  comportement  temps  r§el  et  les  Informations  internes  du  pro¬ 
gramme  teste. 

.  Pour  chaque  action,  les  contrdles  i  effectocr  d4crlts  selon  un  double  point  de  vue  Identtque 
au  precedent.  Pour  chaque  systSme  d'armes,  ce  contrdle  utilise  un  ensemble  d' "images"  deflnles 
au  nlv:>au  de  la  BVL.  Ces  Images  peuvent  slmuler  un  4qulpement  (par  example  visualisations 
"tSte  haute"  ou  "tSte  basse")  ou  simpleioent  regrouper  des  Informations  possedant  une  coherence 
fonctlonnelle. 

-  Ces  tests  sont  ensutte  executes  et  leur  resultat  est  consigne,  constltuant  alnsl  le  DOSSIER  OE 

CERTIFICATION  DES  FONCTIONS  LOCICIELLES. 


Pour  chaque 

-  des  tests 

-  des  tests 

-  des  tests 
aussl  des 
nitres. 


foncilon  logtclelle,  tiois  types  de  tests  sont  effectues  : 

noralnaux,  correspondent  aux  cas  de  bon  fonctlonneraent  du  systdme  d'armes, 

de  pannes,  correspondant  aux  cas  pr4vus  lors  de  la  definition, 

de  pannes  aleatoires,  visant  4  evaluer  la  robustesse  non  seulement  du  programme,  tnals 
specifications  fonctlonnelles  et  pouvanc  alnsl  condulre  a  remettre  en  cause  ces  der- 


(1)  COCODIN  ;  COntrdleur  de  Coherence  P* interface 

(2)  EDL  ;  ^aplon  Oe  ^aboratolcc 
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Lors  de  I'executlon  de  cea  tests,  I'environneaeot  de  cheque  foncclon  est  slmule  a  un  dou^>le 

niveau  : 

-  au  niveau  des  Interfaces  equipement,  en  utlllsant  la  6VL 

~  au  niveau  des  Interfaces  avec  les  aucres  foncclons  logicielies,  en  utlllsant  les  fonctlons  logl-* 
clelles  elles-oemes,  prealableaenc  testees  et  cerclfleea.  Cecl  impose  de  conduire  les  tests 
fonctlonnels  dans  un  ordre  precis,  prenanc  en  coapte  lea  dependences  des  fonctlons  logicielies 
encre  elles. 

Cette  simulation  ne  porte  que  sur  les  interfaces  necessalres  i  la  oise  en  oeuvre  des  tests  ;  en 
partlculler  la  simulation  des  autres  equlpements  du  aysteme  d'armes  n'est  que  partielle. 

Les  prodults  HINERVE  de  cette  etape  sont  : 

-  le  DOSSIER  DES  TESTS  DES  FONCTIONS  LOGIClELLES, 

-  le  DOSSIER  DE  CERTIFICATION  DES  FONCTIONS  LOGIClELLES. 

3.4.  La  validation  du  logtclel 

Les  tests  conduits  pour  vallder  le  loglcl^^l  sont  analogues  aux  tests  fonctlonnels  mals  portent  sur 
le  programme  coiapLet  et  sont  effectues  vls-a-vls  des  documents  de  SPECIFICATIONS  OPERATIONNELLES  Dll 
LOCICIEL  et  de  SPECIFICATIONS  DES  INTERFACF.S  DU  LOGICIEL  (prodults  ?!INERVE  de  I'etape  de  definition  opera- 
tionnelle  du  loglclel).  Les  methodes  et  les  outils  sont  Idenclques  a  ceux  utilises  lors  des  tests  fonctlon¬ 
nels,  En  partlculler,  I'utlltsatlon  de  fonctlons  op^rat lonnelles  valid^es  pour  la  simulation  de  I'envlron- 
nement  d’autres  fonctlons  operationnelles.  Impose,  comiae  pour  les  tests  fonctlonnels,  des  contraintes  de 
sequencement . 

Par  ailleurs,  les  tests  de  validation  sont  proches  de  verltables  scenarios  operat lonnels ,  lls  sont 
regroupes  par  "chalnes  logicielies"  et  non  plus  par  fonctlons  logicielies  et  les  actions  sont  datees  de 
fa^on  representative  vis  1  vis  du  dSroulement  d'une  mission  (une  chalne  logiclelle  represente  la  part  In- 
combant  au  loglclel  dans  la  realisation  d’une  fonctlon  operat lonnelle) . 

Enfln,  le  test  est  conduit  entl^rement  en  hotte  noire  au  niveau  des  Interfaces  opirat ionnelies  et 
les  tests  de  non-rggress Ion  (tests  automat Iques)  sont  utilises  de  fa^on  systematlque.  Ceux-ci  Slaborent 
les  actions  de  mlse  en  oeuvre  du  test  et  le  cumportement  de  reference  i  partlr  des  Informations  enregis- 
trees  lors  du  test  d'un  prograuime  prealablement  certlfle.  Ces  Informations  peuvent  etre  modlftees  raanuelle- 
aent,  lors  de  I’executlon  du  test,  pour  prendre  en  compte  les  Evolutions  de  mlse  en  oeuvre  et  de  contrSle 
llees  ^  celles  du  programme  teste. 

La  validation  du  loglclel  constltue  une  veritable  "recette  uslne”  du  programme  ;  cejul-ci  peut 
Etre  desormals  archlvE  puls  reals  au  mattre  d'oeuvre  du  syscEme  d’armes. 

Les  prodults  MINERVE  de  cette  Etape  sont  : 

-  le  DOSSIER  DES  TESTS  DES  CHAINES  LOGIClELLES, 

-  le  DOSSIER  DE  CERTIFICATION  DES  CHAINF.S  LOGIClELLES  ou  la  conformite  des  resultats  obtenus  a 
ceux  pr^vus  est  consignee  pour  chaque  test  execute, 

-  le  SUPPORT  MATERIEL  et  le  LISTING  du  prograoune  archive, 

-  le  BORDEREAU  DE  LlVRAISoN  DU  LOCICIEL  donnant  la  r^f^rence  de  tous  les  prodults  remis  au 
deraandeor. 
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CHAPITRE  4  :  LES  OUTILS 


Les  outiis  utilises  lors  des  etapes  de  test  du  loglclel  sent  presentes  sur  le  schema  sulvant  : 


3.3 

Tests  unitalres 

IDAS 

3.4 

Tests  d' Integration 

IDAS  COCODIN  EDL 

3.5 

Tests  fonctlonnels 

IDAS  BVL 

3.6 

Validation  du  loglclel 

IDAS  BVL 

Les  outlls  COCODIN  et  RDL,  specif Iques  de  I'etape  de  tests  d' integration,  ont  ete  presentes  succin- 
tement  lors  de  la  description  de  celle-cl.  Les  outlls  IDAS  et  BVL  font  I'objet  d'une  presentation  plus  de- 
talllee  dans  ce  chapltre. 

4.1.  L'outll  IDAS 


IDAS  est  un  systdoe  de  test  de  loglclel  qul  permec  d’ autoreat Iser  le  processus  de  test,  y  cotaprls 
dans  le  domalne  temps  reel.  Le  mode  de  fonctionnement  conslste  i  executer  le  programme  teste,  observer  son 
coraportement  et  verifier  que  ce  dernier  est  conforme  au  comportement  attendu.  Le  champ  d'appllcatlon  ri'IDAS 
est  vaste  car  11  peut  s'adapter  a  tout  langage  de  programmation  (LTR,  Ada,  etc)  de  mese  qu'a  tout  calcula- 
teur  sur  lequel  Le  programme  teste  s'exScute. 

A  ce  tlcre,  IDAS  eat  propose  comae  outll  de  test  sur  I'ateller  ENTREPRISE,  atelier  de  genie  logl- 
clel  portable  multilangage  developpe  a  I'lnltlatlve  de  la  DtiA  pour  I'ensemble  de  ses  applications. 

IDAS  repose  esseutlellement  sur  I'utlllsatlon  d'un  langage  de  test  qul  permet  de  formaliser  les 
tests  effectuea  sous  forme  de  programmes  de  test.  Ceux-cl  peuvent  6tre  archives  et  reexecutSs,  permettant 
alnsl  un  "test  de  non  regression*'  a  chaque  modification  du  programme  teste. 

Ces  programmes  de  test  peuvent  Sere  compiles  ou  interpretis.  Ils  permettent  de  manlpuler,  au  ni¬ 
veau  symbollque,  les  variables  et  les  Instructions  du  programme  teste  (test  bolte  blanclie). 

A  cet  effet,  IDAS  est  connect^  k  la  chatne  de  production  (corapllateurs,  a85<'mbleurs , . . . )  via  un 
post-processeur  qul  fournlc  au  compilateur  et  S  1’ Interpr^teur  d'lDA?  les  Informations  qui  leur  sent  neces- 
aalres  (adresses,  types  de  donates,...). 

Le  sysc^oe  IDAS  peut  Sere  utlllsS  avec  un  sloulateur  du  calculateur  cible.  Selon  les  fonct lonnal 1- 
cSs  de  ce  slaulateur,  I'observation  temps-rSel  du  programme  teste  peut  Stre  rendue  possible  ou  non.  Cette 
configuration  esc  habltuelleroent  utllisee  pour  les  tests  unitalres  et  les  tests  d’ IntSgrat Ion. 

La  configuration  utlllsSe  pour  les  tests  fonctlonnels  et  les  test  de  validation  comporce  une  ma¬ 
chine  de  test  et  un  machine  cible  dlstlnctes  relives  par  une  interface  mac&rlelle  qul  fournlt  les  capacltes 
d'observatlon  teraps-riel  (points  de  concrSle).  Cette  configuration  assure  que  I’execuclon  du  programme 
tests  n'est  pas  perturb^e.  Les  points  de  contr^le  speclflenc  : 

-  des  evenements  simples  survenant  lors  de  I’extcutlon  du  programme  sous  test  (execution  d’une 
Instruction,  manipulation  d'une  variable) 

-  des  elements  complexes  obtenus  par  coniblnatson  logique  d' evenements  simples. 

Ces  points  de  contrdle  ne  sont  pas,  corame  ll  est  courant,  Inseres  dans  le  code,  mats  sont  charges 
dans  I'lnterface  oaterlelle. 

La  structure  generale  du  systeoe  IDAS  est  representee  sur  la  figure  3. 

Le  "noyau''  du  aystSme  IDAS  est  constltue  : 

-  d'un  InterprSteur  qul  permet  une  raise  au  pol.-it  raplde  des  prograirmes  de  test, 

-  d'un  corapllateur  utilise  pour  executer  les  programmes  de  test  prialableraent  devermlnes  a  I'alde 
de  1' Interprfeteur, 

-  d'un  outil  de  raise  au  point  qul  permet  de  locallser  les  erreurs  detectees  lors  de  I'executlon 
des  programmes  de  test. 

Ce  noyau  constltue  une  structure  d’accuell  pour  des  outlls  compleraenialres.  De  tels  outlls  sont 
deji  r&alls&s,  ce  sont  : 

-  un  outll  de  raodelisatlon,  qul  permet  d'exprlmer  un  module  de  comporteinent  en  utlllsant  le  forraa- 
llsne  des  reseaux  de  Petri, 

-  un  outll  de  simulation,  qui  permet  de  substltuer  des  programmes  de  test  a  des  parties  de  program¬ 
mes  testes  non  encore  disponlbles  (Instructions  ou  procedures). 


figure 
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4.2.  L’outll  BVL 

La  BVL  esc  un  ensemble  de  maC^rlels  ec  de  loglclels  peroetcanc  de  tester  dynainlquemerkC  les  logl- 
ciels  des  calculateurs  eabarques  ESD. 

Lore  de  ces  tests,  le(s)  calculateur(s)  eobarqu^Cs)  e8t(sont)  connecce(s)  a  la  BVL  par  ses(leurs) 
liaisons  opgratlonnelles  (bus  et  liaisons  analogiques).  Les  foncClons  realisees  par  la  BVL  consistent  en  ia 
simulation  de  I'environnemenc  reel  du  calcuLateur,  en  I'observatlon  du  conportemenc  du  calculateur  embarque 
au  cravers  de  ses  liaisons  op^racLonnelles  (test  bolce  noire)  et  au  contrdle  de  ce  cooportenenc . 

La  simulation  prend  en  coiapce  une  trajeccolre  avion  d^finle  pour  les  besolns  du  test  et  done  les 
parao^tres  sont  calcules  et  enreglstr^s  en  centre  de  calcul.  L'utlllsatlon  d'une  console  graphlque  permec 
de  sLmuler  les  faces  avant  des  postes  de  comoiande  et  des  visualisations  op&rationnelles.  En  parclculter, 
elle  permet  de  simuler  les  actions  op£raclonnelLes  (actions  sur  les  postes  de  conunande)  et  les  actions  de 
modification  de  I'envlronnement  (ex  :  raise  en  panne  d’equipeDenc) .  Cette  console  permet  Sgalement  de  pre¬ 
senter  les  irtforoations  clrcuiant  sur  les  liaisons  operationnel les  et  des  Informations  Internes  aux  cal¬ 
culateurs  de  test  et  sous  test- 

Les  test  sont  conduits  de  fa^on  manuella  ou  autonatique.  En  test  rnanuel,  la  simulation  des 
actions  operaClonnelles  ec  de  modification  de  I'envlronneiaent  est  realisee  par  I'operateur.  En  test  automa- 
tique,  cecte  simulation  eat  Issue  de  I* enreglstrenent  des  actions  realisees  dans  un  test  ant^rleur  d^nonzm^ 
"test  de  reference".  La  llsce  des  parata^tres  ^  verifier  et  les  valeurs  de  reference  utlltsees  lors  d'ut^ 
test  autoiaatlque  sont  egalement  Issues  d'enreglstrements  r&allses  lors  de  ce  test  de  reference. 

La  structure  raatSrlelle  de  la  BVL  est  representee  sur  la  figure  4. 


figure  4 


La  BVL  est  coi'ipos"<»  de  d®-'*’  sous-ensembles  materlels  princlpauA,  . 

-  Un  systSme  de  mlse  en  oeuvre  et  de  simulation  connecte  : 

.  a  la  liaison  de  mlse  en  oeuvre  des  calculateurs  soas'tesc  (arret/relanre  du  calculateur), 

.  3  des  perlpherlques  standard  :  imprlmante  pour  I'edltlon  des  anomalies,  dtsque  pour  les  Infor- 
matlons  necessalres  aux  tests  automatlqoes  (parametres  de  vol,  paramecres  de  reference,  resul- 
cats  de  tests),  ecran  vldeo/clavler  pour  la  mlse  en  oeuvre  du  sysceme. 

-  Un  syst&iTie  de  gestlon  d*  Interfaces  connecte  : 

.  au(x)  calculateijr(s)  sous  test  par  I ’ Intermedlai re  de  liaisons  operaClonnelles  (liaisons  bus 
et  liaisons  analogtques  discrets  et  synchros), 

.  a  un  ecran  graphlque  dote  d’lnterfaces  sourls/photostyle  sliaulant  les  Interfaces  opera  1 1  onnel- 
les . 
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La  srruccure  loglcleLLe  de  1'-*  ' coaporte  quaCce  «.n3^di0iea  pi  . 

>  an  logiclel  de  generation  de  parametres  de  vul  : 

Ce  logiclel  est  execute  sur  an  materiel  distinct  de  la  BVL  (centre  de  calcul  IBM).  11  eiabore 
des  parametres  de  vol  coherents  relatlfs  3  dea  t'ajectolres  avion  ;  ces  parametres  sont  transmis 
3  la  BVL  sous  un  forioat  compatible  avec  lea  echanges  bus. 

-  Un  loglctel  de  contrSle  de  fonctionnement  de  la  BVL  : 

Ce  logiclel  de  mlse  en  oeuvre  des  fonctlons  de  la  BVL  presence  une  Interface  conversatlonnelle 
realises  sous  foruie  de  touches  fonctlons  programstables  impienentant  des  menus  arborescents . 

Parral  lea  foncltons  prlnctpales,  citons  : 

.  la  mlse  au  point  de(s)  calculaceur(s)  sous  test  au  niveau  symbollque  (hors  simulation  de 
I'envlronnement), 

.  les  tests  de  valldacloo/rececce  (avec  simulation  de  I'envlronnement)  comportant  coimne  sous- 
fonctlons  : 

*  les  modes  de  mlse  en  oeuvre  du(de8)  calculateurCs)  sous  test  :  lancement,  arrSc,  ralentl, 
pas  3  pas  (au  niveau  du  cycle), 

*  la  modification  nanuelle  de  I'envlronnement  (“actions”), 

*  la  selection  du  mode  de  fonctionnement  autoroatlque  des  test-:, 

*  la  selection  des  visualisations  et  des  presentations  (loupe). 

Ce  logiclel  est  execute  sur  le  systems  de  aise  en  oeuvre  et  de  simulation. 

*  Un  logiclel  de  simulation  de  I'envlronnement  : 

Ce  logiclel  est  exicuce  par  le  systeme  de  mlse  en  oeuvre  et  de  simulation.  Pour  chaque  cqulpe- 
ment  Smettant  des  paramecres  3  destination  du(de8)  calculateur(s)  sous  test,  ce  logiclel  assure 
la  simulation  d'un  sous-ensembLe  fonctlonnel  permettant  de  genirer  ces  paramdtres. 

Cette  simulation  est  basee  sur  les  specif Icac tons  des  §quipenents  (specifications  detalllges  des 
fonctlons  op€ratlonnelte8  et  clauses  techniques  d* Int&grat Ion)  pour  I’aspect  fonctlonnel  et  sur 
les  flches  d' interfaces  pour  I'aspect  organlque  des  Ichanges. 

Un  logiclel  de  tests  automatiques  : 

Ce  logiclel  est  execute  dans  le  syst3ae  de  mlse  en  oeuvre  et  de  simulation. 

Son  objectlf  est  double  : 

.  permettre  de  recrler  des  configurations  de  test.  Cette  posslbillcl  est  Inc^ressante  pour 
I'analyse  des  cas  de  panne  en  test  fonctlonnel  et  en  validation, 

.  automatlser  Les  procedures  de  tests  (mlse  en  oeuvre  et  observation  du  coraporteraent)  et 

I'analyse  des  resultats  (comparalson  3  tin  comporteioent  de  refirence).  Cette  fonct  lonnal  I  tfi  est 
part  Iculiere'iient  adapt^e  3  la  recette. 
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CHAPITRE  3  :  L’EVOLUTIQH  DES  TESTS 


L'§volutlon  des  te^cs  de  loglclei,  a  court  et  aoyen  tarae,  ne  se  slcue  pas  cant  au  plan  des  oecho- 
des  ec  des  outiis  de  test  prupreaent  dies  qu'a  celul  de  1* inc^gracion  du  processus  de  test  et  des  aucres 
acLlvices  de  dSveloppemenc  du  loglclel. 

e'est  done  a  I'lmpacc  dG  a  I'apparltlon  d’ouCils  slcues  plus  en  aaonc  dans  le  cycle  de  vie  du  lo- 
giciel  (prlnclpalemenc  des  oucils  d'alde  a  la  specification  de  loglclel)  ec  a  la  tendance  actuelle  a 
I ' Integration  des  outlls  au  seln  d'atellers  de  genie  loglclel,  que  ce  chapltre  sera  princlpaleaent  consacre. 

5.1.  L* Impact  de  I'evolution  des  speciflcactons 

Cette  evolution  se  sltue  a  deux  nlveaux.  D'une  part  la  prise  de  conscience  de  la  crolssance  expo- 
nenclelle  des  couts  des  modifications  au  cours  du  developpement  a  suscltl,  depuls  quelques  annees,  de  nom- 
breux  travaux  dans  Le  domalne  de  la  definition  (et  a  un  molndre  degr§  de  la  conception)  du  loglclel. 

A  I’ESl),  cet  effort  s'est  traduit  par  la  realisation  de  I'outll  DLAO  qul  permeC  d'exprimer  de 
fatjon  seni-foriTielle  les  specifications  de  loglclel.  Les  concepts  de  base  mis  a  la  disposition  de 
I' utlllsateur  sont  : 

-  les  Inf ormat tons  qul  representent  les  donnees  operationnelles  (ex  :  mode  de  fonct lonnement  du 
radar) 


luo  ln>.c4,  LtACca .  aupport  physlque  des  Informations  (ex  ;  codage  utilise  pour  la  transmission  sur 
un  bus  oultlplexe) 

~  les  evenements  qul  modifienc  les  traiceaents  a  effectuer  (ex  :  changement  de  mode  de  fonctlonne- 
ment  du  radar) 

-  les  etats  qul  caract^risent  le  fonctlonneaent  du  loglclel  a  un  instant  donne  (ex  ;  mode  Air-Sol) 

-  les  tralcemencs  qul  repr&sentent  les  taches  ll^mentalres  (ex  :  calcul  de  ballstlque). 

Les  donnees  alnsl  deflnles  par  I'utlllsateur  alnsl  que  les  comaentalres  assocles  sonc  stockes  dans 
une  base  de  donnees  qul  est  alnsl  coujours  d^posltatre  d'une  specification  &  Jour.  De  nonbreuses  posslbiU- 
cSs  d'eiaborer  une  documentation  sont  offertes,  explolcant  les  posslblllcls  d' interrogation  de  la  base  de 
donates. 


Une  telle  formalisation  des  specifications  doit  permettre,  dans  un  futur  asset  proche,  de  progres- 
ser  de  fa^on  significative  dans  I'autoiaatlsaclon  des  tests.  L'ESD  mene  des  travaux  dans  ce  sens,  qui  vlsent 
I  autonaclser  la  generation  de  scenarios  de  test.  L'approche  cholsie  consists  I  generer  an  prototype  I  par- 
tir  d'un  sous-ensetnble  de  la  specification  (definl  par  I'utlllsateur)  puls,  \  partlr  de  stimuli  d'entrie,  a 
produire  des  uouitees  dc  sortie  •xemtlon  de  ce  prototype.  Les  stimuli  d'entree,  qul  constituent  les 
donnees  d’entte«  des  scenarios,  peuvent  Stre  eiaborls  nanuellement  ou  geneies  o  partlr  »  •purification. 
Dans  ce  dernier  cas,  I'utlllsaceur  a  la  posslblllte  de  limiter  les  Informations  Intervenanc  dans  les  scena¬ 
rios  afin  de  prevenlr  le  phenooene  d'exploslon  comblnatolre.  Les  donnees  de  sortie  generies  par  le  prototy¬ 
pe  constituent  les  valeurs  de  reference  utllisees  lore  de  I'executlon  des  scenarios  dr  test. 

5.2 .  L ' integration  des  outlls 

La  prise  de  conscience  des  concepts  du  cenle  Loglclel  conduit  d  une  Integration  de  plus  en  plus 
forte  des  outlls.  Un  exemple  slgnificatlf  est  constitue  par  les  travaux  entreprls  actuellenent  par  le  cons¬ 
ortium  ITI  qul  regroupe  halt  socletes  fran^alses  du  secteur  aerospatlal.  Ces  travaux  vlsent  i  la  realisa¬ 
tion  d'atellers  de  conception  de  systemes  avlonlques  et  de  realisation  de  logiclels  embarquls  et  font 
Tobjet  d'une  presentation  lors  de  cette  conference  (M.  SLISSA  Aerospatiale  et  P.  LAROCHE-LEVY  Avions 
Marcel  Dassault ) . 


De  tels  ateliers  fournlssent  des  reecanlsioes  pulssants  permettant  d'lntegrer  les  outiis  de  Lest.s  et 
les  outlls  de  specification  et  de  conception  des  etapes  symetrlques  (cf  figure  1),  selon  les  prlnclpes  evo- 
ques  au  paragraphe  5.1. 

Ces  mecanlsntes  consistent  prlnclpalemenc  : 


-  en  une  base  d'”objecs*'  centrallsee,  raoyen  de  communlcaltoo  standard  entre  les  outlls, 

-  en  un  systSme  de  gesclon  de  conf igurat Ion  generalise  permettant  d'assurer  une  coherence  perma¬ 
nence  entre  le.s  objets  de  la  base  (specifications,  documents  de  conception,  code,  programmes  de 
tests) • 


Une  raeilleure  Integration  sera  egalement  assuree  entre  les  outlls  de  tests  eix-meraes  (BVL  et  IDAS) 
permettant  alnsl,  a  partlr  du  merae  poste  de  travail,  de  plloter  slraultanement  les  operations  de  tests  fonc- 
tlonnels  et  de  validation  realisecs  par  la  BVL  et  les  operations  de  mlsc  au  point  (de  pannes  llees  a  des 
problemes  temp.s  reel  notaniment)  reaJlsees  par  IDAS. 
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CONCLUSION 


Notre  expirience  du  test  de  loglclel  evlonlque  nous  permet  de  presenter  un  bllan  Isrgeaent 

positif . 

L'objectlC  principal,  c'est-i-'dlce  la  qualite  du  loglclel,  est  attelnt  :  on  constate,  en  vol, 
molns  d'une  erreur  par  an  et  par  prograiuae. 

Nous  mattrlsons  egaleaent  la  tenue  de  nos  couts  et  de  nos  dSlals,  en  d§plt  du  fort  taux 
d’gvolutlon  de  nos  logiclels. 

Nous  constatons  egalement  un  accrolssement  continu  de  notre  productivity.  Celle-ci  s'est  accrue 
dans  un  rapport  volsln  de  5  entre  1979  et  1987.  Cecl  dolt  8tre  ponder^  par  1 '  accroissesent  slatultaiib  de  no¬ 
tre  consoionatlon  en  resaources  ordlnateur,  mats  le  bllan  global  est  posltlf. 

Nos  efforts  tendent  aujourd'hui  3  nalntenlr  cet  accrolssement  de  la  productivity,  et  nous  espyrons 
attelndre  cet  objectlf  par  deux  noyens  prlnclpaux  : 

a)  un  effort  accru  au  niveau  des  tests  unltalres  et  des  tests  d'lntygratlon  car,  coome  cela  a  yty 
soullgny  au  chapltre  5,  plus  tdt  les  erreurs  sont  detectyes  dans  le  cycle  de  vie,  oolns  cou- 
teuses  elles  sont  3  corrlger.  En  partlculier,  nous  comptons  perfectlonner  les  aethodes  et  les 
outlls  nous  pemettant  de  mleux  aaltrlser  les  tauX  de  couverture  de  ces  tests, 

b)  par  une  plus  grande  Intygratlon  de  nos  outlls  de  dlveloppement  au  seln  d' ateliers  de  glnie  lo¬ 
glclel  (Incluant  I'uclUsatlon  de  stations  de  travail  graphlques  i>ult  1-f enStres) ,  et  leur  per- 
aanente  adaptation  aux  aythodea  de  conception  des  ayst3nes  avionlques. 


DISCUSSION 


E.Daley,  UK 

What  implementation  language  is  used  in  flight-critical  systems,  such  as  fly-by-wire  systems,  and  what  is  a  typical 
program  size  for  flight-critical  systems? 

Author’s  Reply 

We  are  not  in  charge  of  flight-critical  systems.  These  are  manufactured  by  the  aircraft  manufacturer. 


G.Bouche,  GE 

Yrni  addressed  software  testing  in  the  development/software  production  phase  for  a  specific  subsystem  How  do  you 
perform  software  testing  in  the  maintenance  phase  ai  the  system  level?  Is  it  the  responsibility  of  rhe  u>.er  Air  Force? 
What  is  the  relationship  to  the  original  producer? 

Author’s  Reply 

Maintenance  testing  at  the  system  level  is  not  our  responsibility.  Errors  delected  during  flight  tests  are  First  analyzed  on 
the  aircraft  manufacturer’s  integration  lest  bench  to  isolate  the  failure-  Then,  the  equipment  is  retested  according  to  the 
general  method  described  (i.e.,  MINERVE).  This  process  includes  completing  different  types  of  forms  (e.g.,  error 
reports)  at  different  levels. 


P.Aouad,  CA 

Your  .software  validation  test  is  limited  to  a  single  box.  Do  you  plan  a  software  validation  test  for  more  avionic'.  using  an 
integrated  test  facility? 

Author’s  Reply 

It  is  not  planned.  It  is  performed  by  a  system  integrated  test  facility  developed  by  ihe  aircraft  manufacturer 


K.L.Edwards,  US 

Avionic  systems  contain  more  and  more  .software,  so  system  reliability  is  more  and  more  a  function  of  software.  D(x*s 
your  testing  enable  you  to  prove  quantitatively  the  reliability  of  your  software,  or  do  you  assume  your  software  is 
perfect  at  the  end  of  your  testing? 

Author’s  Reply 

Of  course,  we  cannot  assume  the  software  is  perfect.  No  one  can.  Actually,  we  have  very  limited  facilities  to  evaluate  the 
reliability  of  our  software.  But,  we  have  some  ongoing  work  on  this  subject,  essentially  at  the  unit  lest  level.  This  can  be 
done  either  by  an  analysis  at  the  source  code  level  or  by  inserting  artificial  errors  and  determining  whether  they  are 
detected  in  the  testing  process. 
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itGuiot,  FR 

Vous  eles  specialiste  de  I'intelligence  artificielle.  vous  n'en  avez  pas  parle.  Pourquoi? 

Reponse  Vuteur 

C  esi  ires  difficile  d’uliliser  ces  techniques.  Cependani,  ccrtaincs  parties  dc  nos  programmes  commencent  a  cue  ecru  en 
PROLOG. 


M.Kayton^  US 

Do  the  Mirage  20(){)‘s  mission  computers  (primary  and  baeVup)  execute  the  same  (c.g..  pertbrm  the  same 

functions).’ 

Author’s  Reply 

No. 
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SUMMARY 

STATE-OF-THE-ART  CAD/CAM  in  this  paper  refers  to  mission-specific  applications  with  the  abilils'  to 
describe  a  design  that  is  independent  of  technology  at  certain  levels.  That  is,  describing  a  design  in  a  manner 
independent  of  any  particular  implementation,  yet  allowing  integrated  verification  across  design  boundaries.  Such 
a  high-level  approach  pays  huge  dividends  in  transferring  designs  in  one  technology  to  another,  e.g.,  bipolar  gate 
arrays  to  CaAs  gate  arrays,  CAD/CAM  TECHNOLOGY  encompasses  more  generic  aspects  of  systems 
development  requiring  a  common  base  or  core  of  computational  tools,  applicable  across  the  spectrum  of 
engineering  dlscipliries.  We’ll  present  some  structures  useful  for  improving  understanding  of  technology,  systems. 
CAD/CAM  and  for  better  communications  across  interfaces.  A  technology  planning  and  communications 
framework  considering  a  hierarchical  systems  schema  is  introduced  for  looking  at  the  spectrum  of  user  tasks  in 
the  life  cycle  of  electronic  products.  The  Navy’s  Acquisition  Strategy  and  Plans  for  Computer-Aided 
Design/Computer-Aided  Manufacturing  (CAD/CAM)  are  presented. 


INTRODUCTION 

The  technology  planning  considerations  of  Figure  1  give  a  broad  overview  of  the  types  of  things  that  are 
important  for  successful  corporate  technology  transfer  and/or  planning.  The  most  critical  item  implied,  bul  not 
specifically  shown  on  Figure  1  and  part  of  any  technology  transfer  planning,  is  optimizing  the  utilization  of  time 
and  resources.  The  industrial  world’s  migration  to  automation  and  robotics  indicates  that  buying,  installing,  and 
learning  how  to  use  new,  more  cost-effective  CAD/CAM  tools  is  part  of  the  answer.  At  issue  are  the  interfaces 
for  communicating  across  boundaries  in  a  structured  CAD/CAM  design  process.  CAD/CAM  technology  interfaces 
are  considered  to  be  an  element  of  both  common  core  technologies  and  mission  specific  environments  depicted  in 
the  systems  acquisition  environment  of  Figure  2.  CAD/CAM  implies  the  use  of  computers  in  systems  acquisition 
activities  from  initial  concept,  through  prototype  testing,  engineering  production,  to  ittiitAiuction  and 
product  support.  An  example  process  would  be  computer-aided  requirements,  specifications,  design,  testing, 
engineering,  processing,  instruction,  training,  manufacturing,  and  logistics.  Structured  definitions  to  identify  and 
define  the  interfaces  needed  for  this  complex  environment  start  with  the  Figure  3  system  acquisition  phases  from 
DOD-STD-2167,  Defense  System  Software  Development.  Another  definition  required  is  for  "system”  which  the 
IEEE  Standard  Dictionary  of  Electrical  and  Electronics  Terms  defines  as: 

"(1)  an  integrated  whole  even  though  composed  of  diverse,  interacting,  specialized  structures  and 
subjunctions,  or 

(2)  an  organized  collection  of  men,  machines,  and  methods  required  to  accomplish  a  specific  objective." 
The  above  definition  doesn’t  explain  what  is  meant  by  the  terms  "interacting,  specialized  structures  or  organized 
collections’*  inherent  in  modern  structured  design.  These  are  the  schemata,  the  plural  of  schema  for  systems. 
Figure  4  shows  a  hierarchical  schema  for  electronic  systems  that  extends  the  definition  of  a  system  to  include  its 
hierarchy.  The  analysis  hierarchy  c<)rrtisponds  to  the  design  or  engineering  process  that  covers  tasks  from  concept 
to  product.  A  hierarchical  schema  to  define  electronic  systems  is  necessary  by  virtue  of  the  way  in  which 
electronic  assemblies  or  systems  are  designed  and  built.  It  wouldn't  be  feasible  to  support  the  life  cycle  activities 
(describe,  design,  evaluate,  partition,  build,  etc.)  of  today's  complex  avionics  systems  without  this  sophisticated 
hierarchical  structure  to  verify  and  determine  intended  and  resultant  operational  characteristics  such  as  response, 
reliability,  fault  tolerance,  and  other  behavioral  limitations,  because  in  modern  environments,  physical  systems  arc 
directly  linked  to  system  models  via  tests,  measurements,  and  diagnostics  as  indicated  in  the  interfaces  depicted  in 
Figure  4.  System  models  are  a  sensitive  information  area  for  the  militarv';  they  form  the  basis  for  calculating 
performance  information  used  to  identify  areas  of  improvement  for  upgrading  systems  and  to  evaluate  limitations 
and  measure  the  most  effective  way  to  employ  and/or  defeat  a  system. 


SATISFYING  THE  NAVY’S  CAD/CAM  TECHNOLOGY  NEEDS 

By  reflecting  optimization  of  time  and  resources  to  the  lowest  levels,  higher  productivity,  efficiency,  and 
competitiveness  in  performing  the  following  identified  tasks  is  needed: 
a.  Assistance  in  automating  typical  tasks  such  as: 

1)  Select,  plan,  and  trade-off  methodologies,  styles,  and  tools  appropriate  for  a  structured  design  process. 

2)  Build  hierarchical  models  by: 

a)  Decomposition  and  partitioning. 

b)  Developing  testing  criteria  by  defining  hardware,  software,  and  associated  test  vectors.. 


I*  TECHNOLOGY  PRESENTLY  AVAILABLE . NOW  i  FOR  CRITICAL  EXPERIMENTS) 


*  TECHNOLOGY  AVAILABLE  FOR  PRODUCT  IMPROVEMENTS . LOW  RISK  1-2  YEARS 

HIGH  RISK  3-5  YEARS 

*  ADVANCED  technology 

FOR  PRE-PLANNED  PRODUCT  IMPROVEMENTS . LOW  RISK  5-7  YEARS 


TECHNOLOGY  TIME  FRAMES 


*  RESEARCH 

*  DEVELOPMENT  (EVALUATION)  AND  TECHNOLOGY  TRANSFER 

a.  INFORMATION  GATHERING  AND  DISSEMINATION 

b.  TRAINING  AND  ASSISTANCE 

C,  PHYSICAL,  FINANCIAL,  AND  HUMAN  RESOURCES 
TECHNOLOGY  INITIATIVES  AND  PHASES 


*  LOGICAL 

STRONG  LOCAL  RESEARCH  EFFORTS 

SKILLED  POOLS  OF  LABOR 

AVAILABLE  FINANCING 

PRESENCE  OP  CORPORATE  HEADQUARTERS 

TRANSPORTATION 

CLIMATE  AND  CULTURAL  AMENITIES 

*  OTHER  (PLANNING  is  worthless  Without  a  strategic  vision  and  goals) 

IDENTIFICATION  AND  FOCUS  ON  NEEDS/REQUIREMENTS 

anticipate  the  future  and  reflect  to  the  lowest  levels 
ADAPTATION  TO  INTERNAL  AND  EXTERNAL  CONSTRAINTS 

LINKAGE  WITH  BROADER  DEVELOPMENTS  (options  succeed,  either/or  fails) 
LOCAL  INITIATIVE  AND  PARTNERSHIP  WHICH  WILL  DEVELOP  SUPPORT  NETWORKS 
and  bring  local  representatives  into  the  design  and 
implementation  of  the  initiatives 
SUSTAINED  EFFORTS  and  GROWTH  via  coordinated  individual  efforts 

FACTORS  AFFECTING  SUCCESSFUL  DEVELOPMENT 


(  BETTER  WEAPONS . FASTER  DESIGN  CYCLE  t 

I  USABILITY,  AVAILABILITY,  AFFORDABILITY,  PERFORMANCE j 


I  . . . 

i  I  a.  &  b.  TRAINING 

I  - - - 

I  I 

,  -  - 

-I  b.  4  C.  TOOLS 


I 


- 1  c.  components/projects  t  — 


COMPONENTS  AFFECTING  SUCCESSFUL  DEVELOPMENT 


FIGURE  1,  TECHNOLOGY  PLANNING  CONSIDERATIONS 


c)  Support  structured  hardware  and  software  codesign  to  allow  inij>lementation.  performance,  and 
interfaces  to  be  identified  so  they  can  be  evaluated, 

3)  Verify  subsection.s  of  a  larger  system  at  the  levels  of  analysis  shown  in  Figure  4  b\  evaluating 
simulated  test  and  performance  measurements  of  a  design  against  requirements  and  constraints. 

a)  Validate  that  the  design  meets  allocated  or  predicted  reliability  and  diagnostics  (testability) 
requirements. 

b)  Validate  the  physical  design  prior  to  committing  to  fabrication  and  procurement  via  sophisticated 
models  and  .simnlatiims. 

4)  Extract  data. 

5)  Layout  and  simulate. 

6)  Establish  a  documentation  bast*  line. 

CapabilitS’  f<)r  top-doun  design  and  a.vsessment. 

1)  Allow  designers  to  work  at  a  higher  level  in  the  Figure  4  hierarchs  to  reduce  design  errors  and  times. 

2)  Each  user-created  <jb)ect  or  mcnlel  mat  have  a  minimum  structure  and  hierarchy  of; 

a)  Pha.se  (see  F'igure  3). 

b)  Level  (see  Figure  4). 

c)  Version. 

d)  Date. 

e)  Information  categories  ol  Figure  3  associated  with  levels  of  Figure  4. 
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FIGURE  2.  SYSTEMS  ACQUISITION  ENVIRONMENT 
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Classes  of  models  in  the  system  life-cycle  model  correspond  to  the  numbers 
in  the  table  below.  The  classes  are  defined  as  good  enough  for: 

1)  Research  and  concept  exploration. 

2)  Schematic  and  limited  analysis  to  build  a  prototype  that  will 
function  correctly. 

3)  Analysis  in  the  hierarchy  of  Figure  4. 

4)  Safe  use,  reliable  operation,  and  affordable  maintenance  of  the 
product  by  the  Fleet. 


FIGURE  3.  SYSTEMS  ACQUISITION  PHASES 


Capability  for  bottom-up  implementation: 

1)  Determine  consistency  and  completeness  of  information  transmitted  between  groups  working  on  a 
partitioned  design  or  between  levels  of  a  design: 

a)  Requirements. 

b)  Sp>ecifications. 

c)  Functional  performance  measurements. 

d)  Functional  performance  constraints. 

e)  Algorithms,  test  vectors,  and  diagrams. 

f)  Hardware/software  architectures. 

g)  Information  categories  of  Figure  3  and  4. 

2)  Verify  the  design  as  it  progres.s€S  incrementally  from  one  level  to  the  next  in  the  design  hierarchy;  or 
from  one  phase  to  the  next  in  the  life  cycle  through: 

a)  Control  and  verification  of  the  configuration  to  reduce  errors  throughout  the  design  cycle. 

b)  Design  database/documentation  detailing  the  original  design  and  its  history  to  facilitate 
refabrication,  redesign,  and  maintenance  of  the  configuration. 

c)  Incremental  verification  of  the  completed  design  against  the  design  database  elements  of  Figures  2 
and  3,  and  the  levels  of  Figure  4  by  controls  and  measurements  of  what; 

1.  Checks  have  been  done. 

2.  Constraints  have  been  met. 
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1)  Information  translators  will  be  based  on; 

a)  IGES/PDES  for  graphic  information. 

b)  VHDL  and  EDIF  for  non-graphic  information. 


FIGURE  4.  INTERFACES  OF  THE  ELECTRONIC  SYSTEMS  AND  ANALYSIS  HIERARCHIES 


CAD/CAM/CAE  IMPLEMENTATION  PROBLEMS,  DIFFERENT  LEVELS,  DIFFERENT  NEEDS 

Not  only  are  modern  electronic  designs  impossible  to  accomplish  without  desig.i  automation  tooU  but 
engineers  in  government  and  industry  are  faced  with  ever  increasing  design  times  because  of  increased  complexit\ 
caused  by  miniaturization.  For  example,  approximately  5  Gbytes  of  design  data  are  required  to  describe  a 
300K-transistor  device  such  as  Motorola's  68030  microprocessor.  The  number  of  primitives  we  can  put  on  a  silicon 
chip  is  presently  growing  at  an  exponential  rate.  Integrated  circuits  containing  over  two  million  transistors  are  on 
the  drawing  board;  their  macros  are  under  fabrication.  These  devices  are  among  the  most  complex  things  man 
has  built  with  large  teams  of  researchers  working  on  their  eventual  realization.  Not  only  are  very  large  systems 
continuing  to  shrink,  but  a  complexity  corresponding  to  neural  network  structures  of  the  brain  is  rapidly  being 
approached.  These  devices  are  multi-systems  and  are  every  bit  as  complex  as  the  number  of  de\'ices  the\-  contain 
implies.  Thus,  it  is  painfully  obvious  to  design  engineers  at  the  lower  levels  that  complex  design,  development, 
and  product  integration  may  only  be  accomplished  within  a  reasonable  time  by  off-loading  the  mundane,  time- 
consuming,  "stupid’*  tasks  to  computers.  This  is  at  a  lower  level  than  Artificial  Intelligence  (AI)  acti\ities  which 
are  focused  on  the  next  level  up  of  adding  more  intelligence  to  computer  tools.  The  thrust  of  this  next  le\el  up  is 
to  off-load  tasks  such  as  dc.sign  or  electrical  rule  checks  that  require  some  intelligence  buried  in  the  design  tof)l  or 
database  .so  that  the  computer  may  act  as  a  design  assistant.  The  next  step-up  from  this  is  to  specif)  open 
architecture  CAD/CAM/CAE  systems  that  will  allow  for  the  integration  of  multiple  vendor  tools  with  an  eye 
toward  full  implementation  of  AI  tools. 


j  Diagnostics/ j 
(Tests/  I 
I  Measurements  I 


SATISFY  FRONT-END  ACTIVITY  NEEDS  FIRST.  FOR  THE  HIGHEST  PAYOFF 

The  Computer-aided  software  engineering  environment  has  developed  data  which  shows  that  the  earlier 
errors  are  found,  the  cheaper  it  is  to  correct  them:  the  cost  of  correcting  errors  grows  rapidly  with  time.  This 
principle  requires  designs  be  "•■un  through  the  mill"  a.s  early  a.s  possible  for  their  esaluation.  The  lesson  here  is  to 
support  a  thorough  understanding  and  evaluation  of  the  system  development  /r  life  c>cle  pha.ses. shown  in  Figure 
4.  and  target  maximum  inxe.stinent  in  the  early  phase.s  of  development  for  maximum  payoff. 


THE  U.S.  NAVYS  APPROACH  TO  CAD/CAM  DESIGN  AUTOMATION 

The  Navy  has  been  implementing  a  three-phased  strategy^  to  provide  its  workers  with  state-of-the-art.  eovt- 
effective  CAD/CAM  tools  to  achieve  a  better-engineered,  more  maintainable  product  than  ever  before  and  to 
satisfy  its  front-end  .leeds. 


PHASE  ONE— THE  FIRST  ACQUISITION 


The  Navy  embarked  on  the  first  phase  of  its  desi^  automation  strategy-  in  IWSl  with  a  \a\\-wide 
centralized  procurement  known  as  CAEDOS  (Computer  .\ided  Engineering  Documentation  Ssstem).  This 
acquisition  was  a  99.9  million  dollar  contract  from  1981  to  run  through  the  middle  of  1988  and  pro\ided  a 
minimal  number  of  CAE  systems  to  a  small  portion  of  the  Navy.  The  major  problems  encountered  in  this 
introduction  of  design  automation  in  1981  were  not  technical,  but  were  related  to  the  nature  of  p>eople;  the\ 
were  asked  to  accept  and  embrace  something  new.  This  new  technology  was  sophisticated,  complex,  and  difficult 
to  use  without  extensiv’e  training  It  was  a  new  way  to  do  a  job  and  required  technical  guidance,  extensive* 
training  and  motivation  on  the  part  of  the  users  to  get  involved  in  doing  their  jobs  better  by  making  use  of  this 
advanced  technology.  It  was  embraced  by  those  who  had  a  desire  to  do  something  new  and  better.  Whether  or 
not  it  was  successful  depends  on  your  point  of  view.  The  CAEDOS  acquisition  demoastrated  the  viability  of  a 
centi<iUzed  contract  vehicle  for  activities  to  buy  state-of-the-art  technologv'  at  significant  price  reductions  but  it 
didn’t  solve  the  problem  of  what,  how  and  where  to  obtain  teciii.'cal  guidance  in  effective  application  of  new 
technology.  Technology  education  and  acceptance  are  separate  prob»«.  ns.  The  problems  are  the  same  ones 
American  education  has  today,  how  to  effectively  train  and  motivaU  people  to  do  their  best.  There  are 
indications  that  some  CAEDOS  assets  are  falling  into  disuse  today  due  in  most  part  to  the  fact  they  have  been 
surpassed  by  technology  which  is  cheap  to  obtain  and  much  easier  to  use.  In  isolated  cases  the  lack  of  economies 
of  production  have  caused  these  assets  to  fall  into  disuse.  Adequate  individual  training  and  technical  guidance  in 
applications  is  a  continuing  problem  which  is  being  addressed  in  the  second  acquisition  specification  by  requiring 
built  in  features  to  address  these  needs. 


PHASE  TWO— THE  SECOND  ACQUISfTfO-' 

The  Navy  is  presently  looking  at  benchmarks  for  evaluating  what  to  procure  for  its  CAD/ CAM  second 
acquisition.  This  second  acquisition  is  an  ambitious  effort  which  has  a  user  developed  specification  that  was 
released  by  the  Navy  to  industry  early  in  1986.  The  proposed  systems  are  to  provide  cost  effective.  commercialK 
available,  non-deveiopmental,  tools  to: 

a.  Shorten  the  design  cycle. 

b.  Promote  better,  less  expensive  designs: 

1)  Build  in  reliability,  ma.ntainability’.  and  availability  of  equipment  in  the  design  process  itself: 
structured  design  is  a  feature  of  the  tool  set. 

2)  Manage  configuration  over  a  product's  life  cycle  for  early  design  capture  with  self  documenting  and 
instruction  features  built  into  the  tools  to  attract  and  train  users  in  a  natural,  friendly  environment. 

The  hardware  and  proposed  software  tool  sets  in  the  specification  are  vertically  integrated  within  five  award 
bands  defined  by  NAVSEA,  NAVAIR,  NAVSUP.  NAVFAC,  and  SPAWAR.  The  specification  identifies  and 
defines  the  hardware  components  shown  in  Figure  5,  linked  through  a  local  area  r^etw’ork  also  defined  in  the 
specification.  An  open  architecture  analogous  to  Figure  2,  consisting  of  core  functions  common  to  the  different 
Navy  Systems  Commands  with  mission  specific-software  on  top  of  this  core,  is  being  stressed. 

Once  the  technical  hurdle  of  identifying  the  systems  to  do  the  defined  tasks  has  been  accomplished,  some 
figure  of  merit  to  measure  the  cost  benefits  must  be  "bottom-lined.”  Let’s  compare  a  production-oriented  private 
corporation  against  a  design-oriented  government  agency  to  investigate  the  development  of  a  quantifiable  figure- 
of-merit  with  some  common  ground  in  this  spectrum. 

A  private  company  derives  economies  of  production  in  an  integrated  design,  manufacturing,  marketing  and 
service  environment.  The  design  engineers  in  the  private  sector  are  more  likely  to  be  tightly  coupled  with  the 
production  engineers,  salesmen,  and  service  technicians  and  the  desired  result  is  a  producible  more  maintainable 
design;  competition  forces  industry  to  "design  to  production  and  cu.stomer  satisfaction.”  The  mass-produced 
component  rolls  off  the  assembly  line  with  quantifiable  regularity  or  the  team  established  to  maintain  the  product 
line  doesn't  have  a  job. 

In  contrast  is  the  design  that  never  appears  (with  emphasis  on  appears)  to  go  anywhere.  The  output  is 
nothing  more  than  a  design  database  which  describes  a  design  and  is  commonJ>  '  Jed  a  drawing  package. 
Drawing  packages  are  classified  mto  levels  roughly  corresponding  to  their  completeness  (system  phases)  and.  or 
verified  accuracy;  level  3  drawings  follow  many  standard  conventions  and  invariably  require  the  services  of  a 
competent  draftsman  who  understands  these  standards.  The  element  of  enlightenment  that  often  escapes  the 
reviewer  of  a  design  database  or  drawing  package  is  the  technology  required  to  get  that  ‘intermediate”  output. 
Yes.  a  design  database  (commonly  a  digital  database)  is  nothing  more  than  an  intermediate  form — as  ypf  an 
non-quantifiable  product.  It  is  the  culmination  of  the  research,  engineering  prototype,  or  engineering  development 
phase  required  to  describe  the  product  to  be  produced.  In  many  firms  and  government  agencies  this  intermediate 
form  has  been  the  end-product.  In  firms  specializing  in  design  database  development,  obsolete  CAD  CAM  CAE 
.systems  become  nothing  more  than  2-D  automated  drafting  tools  to  offset  the  costs  associated  with  their  purchase. 
Productivity  has  been  measured  on  near-term  investment  return  rather  than  against  a  more  reliable, 
maintainable,  or  available  design  which  can  be  verified  through  sophisticated  simulations  of  the  product  before 
funds  are  committed  to  production. 
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FIGURE  5.  open  ARCHITECTURE  OF  THE  NAVY'S  CAD/CAM  SECOND  ACQUISITION 


TRANSFER  TECHNOLOGY  GRACEFULLY 

The  Second  Acquisition  plans  to  provide  hardware  and  software  deliverables  which  will  be  the  leading  edge 
of  technology.  The  specification  looks  into  the  near  future  and  reflects  this  future  to  the  needs  at  the  lowest  levels 
of  design  tasks.  The  document  is  unparalleled  in  private  industry  because  it  provides  a  cohesive  view  of  the 
direction  automation  is  heading  from  diverse  viewpoints.  It  calls  for  a  full  spectrum  of  vertically  integrated  design 
tools  in  mission  spectra  which  correspond  to  the  Navy’s  Systems  Commands  yet  has  a  common  core  upon  which 
to  build  these  diverse  applications.  The  inputs  from  industry  were  used  to  help  scale  the  document  to  reality  so 
that  the  CAD/CAM  systems  to  be  benchmarked  in  1987  will  in  fact  be  the  yct-to-be-announced  products 
scheduled  for  release  in  1988  or  the  leading  edge  products. 

These  leading  edge  tools  must  be  phased  into  tasks  for  which  they  are  appropriate  and  will  give  the  highest 
payoff.  There  will  be  problems  of  introduction  and  careful  nurturing  of  the  user  base  will  be  necessary  during 
their  infancy  in  1988.  The  CAD/CAM  tools  will  be  in  danger  of  falling  into  disuse  as  a  result  of  lack  of 
understanding  their  power  or  full-function  capabilities,  particularly  in  reducing  costs  of  designing  to  production 
constraints.  History  has  shown  that  centralized  procurements  fail  when  the  user  base  is  not  represented. 
Fragmented  procurements  result  in  a  fragmentation  of  common  database  information  and  a  fragmentation  of 
design  principles.  This  exacerbates  “islands  of  information”  problems  even  within  single  activities.  A  structured 
approach  must  be  pursued  to  allow  a  standardization  of  communications  and  design  principles  resulting  in 
maximum  utilization  of  shared  resources,  including  peripherals  and  design  data. 


FUNNELING  TECHNOLOGY 

There  are  two  steps  to  the  approach  to  injecting  CAD/CAM  technology  within  the  context  of  the  Second 
Acquisition.  The  objective  of  the  first  step  is  to  le^  a  separate  contract  award  for  each  Systems  Command  as  a 
part  of  the  Second  Acquisition.  To  perform  this  task  in  a  coordinated  fashion  requires  a  dedicated  Technology 
Office  within  each  Systems  Command  to  address  technology  issues  specific  to  the  different  missions. 


rhf  ubjefti\(.‘  (){  the  second  step  i»f  the  Second  Aetpiisition  is  to  provide  what  is  called  "techiioloLW  reiresh 
ihroui'h  centralized  ^uidaiice  and  expertise.  "Refresh"  addresses  evaluating  the  icsefulness.  apj^ropriateiiess  and 
availabilitv  of  CAD  C.^M  technology  a.s  it  evolvc'S  in  private  industry  and  is  reads  to  be  used  to  solve  Navv 
problems  applicable  to  its  large  user  bast*.  This  rerjuires  in-depth  knowledge  of  design  efforts  throughorit  the 
Navy,  with  particular  attention  being  paid  to  the  methodologies  and  design  techniijues  being  applied  m  field 
agencies,  and  a  technologv  group  attuned  to  evolving  requirements  and  solving  real  problems,  Missioii-siwific 
Technology  Offices  formed  to  address  Second  .Acquisition  CAD  C.AM  application  problems  w  ill  become  well- 
versed  in  C.AD'CAM  procurement  and  implementation  techniques  and  will  he  capable  of  injec'tion  of  this 
technologv  into  their  ow  n  organizations  through  their  relation.ship  and  association  w  ith  ])riv  ate  indiistrv .  other 
acquisitions, and  other  Technology  Offices.  The  participants  within  each  office  must  l>e  classified  a.s  technologi.sts 
and  miLst  be  fully  cognizant  of  current  research,  prototype  and  engineering  development  and  manufacturing 
efforts  at  the  various  N’av>  agencies  in  order  to  react  dynamically  to  user  rtxjuirements.  Office  jxrscmnel  will 
funnel  evolving  u.ser  rerjuirements  to  industry  in  an  effort  to  furnish  vendors  advanced  information  t>n  where  to 
focus  their  advanc-ed  products.  Only  through  this  type  of  dynamic  information  interchange  will  technologv  refresh 
make  sense  in  the  context  of  the  Second  .Acquisition.  Serving  as  a  repository  of  technical  information  on  Navy 
CAD/CAM  .systems,  the  Technologv-  Offices  will  be  looked  upon  as  invaluable  resources  that  will  champion  strong 
cases  made  by  the  user  ba.se  and  binnel  industry  standards  to  these  same  users  in  a  structured  manner.  The  full 
gamut  from  design  to  product  can  be  addresst*d  through  this  highly  integrated  and  structured  approach. 


PHASE  THREE— THE  THIRD  ACQUISITION 

The  Third  Acquisition  will  take  the  Navy  into  the  next  century,  providing  a  fully  integrated  CAD  CA.VI  (^AE 
•system  for  Navy  scientists,  engineers,  and  other  |x*rsonnel.  The  third  pha.se  for  full  horLontal  and  vertical 
integrathin  i.s  slated  for  beyond  1992  of  this  multi-year,  three-phase  effort.  Total  integration  means  a  single 
computer-aided  environment  schemata  for  accomplishing  concept  to  product  and  support  in  all  the  engineering 
disciplines,  The  goal  i,s  to  have  total  or  inaxiinaljv  optimized,  integrated  jystem.s  across  technical  life-cvclc 
applications  in  the  Navy  to  fully  integrate  lx)th  vertically  and  horizontally,  linking  and  cross-linking  proces.ses. 
thereby  establishing  a  centrallv  controlled,  cradle-to-grave  warfare  system  model  with  dist'-jbuted  simulations  of 
system  coornponcnl.s.  This  concept  will  evolve  through  the  efforts  oi  technologv-  planning  at  all  levels  to  provide 
migration  paths  for  govcrnriient,  academia,  and  indastry  efforts.  Development  of  the  concepts  and  standards 
needed  for  evolution  to  and  implemenlatUm  of  the  Third  Ac(|uisition  will  only  lx*  attained  bv  close  cfKjperation 
and  relationships  on  an  international  scale. 
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Summary 

Fundamental  problems  in  interfacing  and  integrating  information  between  diverse 
design  systems  are  examined.  Specifically  problems  associated  to  the  contexts  of 
meaning  that  are  required  to  understand  information  in  diverse  systems  are  examined. 
Increased  research  into  a  general  theory  of  design  is  advocated.  The  resolution  to  some 
integration  problems  is  suggested  on  the  basis  of  recent  developments  and  experience 
with  a  functional  design  theory. 


1.  Introduction. 

There  is  now  considerable  technological  movement  towards  the  use  of  automated  design  systems  in  the  design  of 
mechanical  components  of  systems,  m  the  design  of  VLSI  components,  and  in  the  design  of  software  systems.  Each  of 
these  activities  have  proceeded  in  parallel,  without  a  great  deal  of  crxirdination  and  cross  fertilization  of  technologies, 
with  the  result  that  it  is  becoming  increasingly  difficult  to  establish  interfaces  between  these  systems  or  develop  an 
integrated  approach  to  the  entire  system  design  problem. 

At  the  same  lime,  there  are  a  number  of  ideas  and  principles  common  to  the  design  systems  being  developed  for 
different  technologies.  Most  of  these  systems  have  a  means  of  specifying  the  requirements  of  the  design,  all  have  some 
means  of  describing  the  components  of  a  design,  and  all  have  some  means  of  describing  designs  in  terms  of 
components.  Some  systems  use  the  technology  of  expert  systems  to  aid  in  the  design  process.  There  are  a  variety  of 
user  interfaces  to  the  information  in  these  systems,  so-called  views.  Some  views  are  oriented  to  the  designer,  some  to 
the  system  design  management  process,  and  some  to  the  manufacturing  or  implementation  process.  The  requirement 
for  multiple  views  or  multiple  interfaces  within  a  single  system  is  being  generally  acknowledged  as  an  important 
concept 

Yet  the  possibilities  of  developing  and  integrating  these  diverse  systems  into  a  single  system  still  seems  remote, 
and  fortunately,  may  be  undesirable  at  the  present  lime.  Close  coupling  between  diverse  technologies  could  seriously 
impede  progress  in  any  one  of  them.  At  the  same  lime,  there  is  a  need  for  some  coupling.  There  is  a  classical  Uadcoff 
here.  Should  a  system  be  integrated  so  that  it  optimizes  the  interaction  of  information  among  all  those  who  know  it. 
but  forces  the  user  to  express  himself  in  limited  ways,  or  should  there  be  a  variety  of  expressions,  and  thus  increase 
expressivity  of  individual  environments,  but  correspondingly  decrease  the  communication  between  them? 

A  middle  solution  lies  in  providing  means  for  standardizing  the  interface  methodology  between  a  variety  of 
systems.  As  a  first  step,  it  would  be  an  improvement  if  we  could  develop  a  means  of  uniformly  relating  information 
in  one  type  of  environment  to  information  in  other  environments.  This  would  provide  a  means  of  transmitting 
information  from  one  environment  to  another  in  a  systematic  manner.  The  problem  of  doing  this  is  similar  to  the 
problem  of  having  a  standard  internal  representation  of  information,  for  which  multiple  views  are  possible,  but  which 
establishes  a  consistency  between  views,  in  a  single  system.  These  problems  arise  equally  in  mechanical,  VLSI,  or 
software  design  systems.  It  is  the  information  capture  problem. 

There  is  another  issue  here.  Up  to  the  present  time,  system  design,  in  each  of  the  technological  areas  in  which  it 
is  expressed,  has  not  had  a  theoretical  basis.  It  is  in  the  same  slate  as  other  disciplines  in  an  early  stage;  a  collection  of 
techniques,  tools,  and  unformulated  processes  in  the  minds  of  users.  This  will  probably  remain  an  essential  fact  in 
system  design  for  some  time  to  come.  However,  the  demands  of  the  problems  that  need  to  be  solved,  and  the  need  for 
capitalizing  on  previous  efforts  create  a  need  for  formulating  established  principles  and  techniques.  Such  a  process  is 
one  toward  greater  generality  and  abstraction,  ai  d  ultimately  leads  to  a  belter  understanding  of  the  processes  themselves. 

The  pnmary  objective  of  this  paper  is  to  describe  a  limited  methodology  for  describing  system  functional  design 


infonnation  independently  of  the  technology  used  to  realize  the  design.  That  is.  in  terms  of  'what',  rather  than  'how'. 
This  methodology  can  be  used  to  establish  interfaces  between  various  design  environments  by  establishing  a  way  of 
describing  design  information  independently  of  its  technological  idiosyncrasies.  In  some  sense,  it  provides  a 
methodology  for  describing  a  view  of  a  design  component  in  terms  of  its  interface  to  the  outside,  without  regard  to  how 
its  properties  are  achieved.  Equivalently,  it  provides  a  means  for  modeling  and  manipulating  design  elements  absuacUy. 
Yel  it  is  also  general  enough  and  precise  enough  to  describe  specific  technological  properties  of  design  elements  when 
required.  An  important  feature  of  this  methodology  is  that  it  has  a  rigorous  theoretical  basis.  This  is  a  feature  we  feel 
is  lacking  in  many  existing  approaches  to  design.  Also  this  paper  is  a  report  on  work  in  progress  toward  the  goal  of 
achieving  true  'resource  abstraction';  the  goal  of  describing  and  designing  systems  in  formal  terms,  so  that  design 
problems  can  be  solved  in  principle,  not  just  in  terms  of  a  current  technology. 

In  the  following,  we  establish  the  background  of  issues  and  ideas,  ihcn  introduce  the  general  principle  of  functional 
abstraction  ,  and  then  a  specific  theory  of  resource  abstraction.  Next  we  illustrate  these  ideas  with  a  simple  example, 
and  conclude  with  some  remarks  on  future  directions. 

2.  Background. 

The  primary  reason  that  it  is  difficult  to  develop  interfaces  between  different  design  systems  is  for  the  same  reason 
that  it  is  difficult  to  develop  interfaces  between  any  two  computing  systems.  There  are  few  standard  methods  for 
describing  general  information.  Even  the  simplest  types  of  information,  such  as  a  yes/no  answer  to  a  question  has  no 
consistent  representation  in  a  computer.  We  must  begin  with  this  fundamental  problem  if  we  intend  to  establish 
interfaces  between  a  variety  of  systems. 

In  spite  of  the  fact  that  there  are  ISO  and  IEEE  efforts  to  standardize  many  aspects  of  the  design  process,  such  as 
ADA.  VHDL  (VHSIC  Hardware  Description  Language),  EDIC  (Elccuonic  Design  Interface  Format),  ICES  (Initial 
Graphics  Exchange  Standard)  and  PDES  (Product  Description  Exchange  Standard),  it  is  neither  necessary,  nor  is  it 
practical,  to  expect  that  universal  standards  could  be  formulated  and  enforced  across  a  wide  spectrum  of  design  activities. 
Although  standards  can  be  imposed  successfully  witihin  a  limited  context,  experience  has  shown  that  broad  standards 
are  generally  unenforceable  and  tend  to  consTain  the  free  development  of  technologies  and  ideas.  System  design  is  in 
an  early  stage  of  development,  and  it  would  be  premature  to  fix  on  immature  concepts  or  principles.  On  the  other  hand, 
total  chaos  is  also  counterproductive  to  our  ability  to  capitalize  on  knowledge  in  one  domain  by  applying  a  similar 
knowledge  in  other  domains.  This  is  the  problem  that  is  already  manifesting  itself  today.  The  solution  is  to  find  some 
reasonable  middle  ground.  This  middle  ground  must  be  based  on  something  that  is  fundamental  to  all  design  systems. 
We  need  to  view  the  processes  of  design  in  abstract  terms  and  synthesize  elements  of  the  process  as  practiced  in  its 
various  contexts. 

All  design  systems  presuppose  a  collection  of  elements  that  arc  combined  to  form  a  design.  A  design  establishes  a 
juxtaposition  of  and  interrelations  between  these  elemental  components  to  achieve  a  desired  result.  Design  is  inherently 
hiearchical,  in  tf  it  the  result  of  design  at  one  level  can  become  elemental  components  at  another  level.  The  properties 
of  the  design  follow  in  some  complex  way  from  the  properties  of  the  elemental  components  and  the  way  that  these 
components  are  combined.  The  hierarchical  nature  of  design  also  reflects  the  fact  that  our  primary  strategy  for  handling 
complexity  is  divide  and  conquer. 

In  some  cases,  design  elements  are  physical  abstractions  that  represent  some  material  object.  In  other  cases  they 
are  functional  abstractions  that  represent  constructs  from  mathematics  or  a  field  of  engineering.  Some  of  the  aspects 
of  the  process  of  design  represent  temporal  properties  of  the  sytem  as  opposed  to  static  properties.  In  fact,  it  is  a  safe 
generalizauon  to  say  that  alt  design  systems  have  physical,  functional,  and  temporal  dimensions.  A  design  consists  in 
elaborating  a  hierarchy  of  components  that  are  interrelated  in  each  of  these  dimensions  and  combine  to  create  a  complex 
resource.  At  our  present  state  of  knowledge,  a  unified  theory  that  can  handle  all  these  dimensions  is  too  much  to 
expect. 

In  practical  situations,  there  is  usually  a  great  deal  of  information  about  design  components  that  is  assumed  by  the 
designer  as  part  of  general  knowledge  of  a  technology.  This  information  about  components  is  not  expressed  in  the 
system,  and  may  be  only  vaguely  understood  by  its  users.  In  most  cases,  users  must  expend  a  considerable  effort  just 
to  learn  the  context  neces.sary  to  use  a  particular  system.  This  is  one  fact  that  makes  the  interfacing  and  integration  of 
design  systems  so  rfifficult.  In  order  to  pass  information  from  one  system  to  another,  or  even  one  part  of  a  system  to 
another  part,  we  have  to  have  some  confidence  that  the  information  .  ;  meaningful.  This  is  the  'semantic  gap' 
problem.  There  is  a  gap  between  what  a  design  component  is  in  the  system  and  what  it  is  in  the  mind  of  a  user.  At  the 
current  state  of  the  art,  the  designer  bears  the  burden  for  this  discrepcncy  and  may  have  little  or  no  automated 
assistance.  Even  if  the  system  has  means  for  capturing  the  meaning  of  a  descnpiion  in  the  system,  such  as  some  rule 
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based  reasoning,  it  is  still  difficult  to  export  this  information  to  another  system  because  its  meaning  requires  the  proper 
context.  We  can  illustrate  the  problem  with  a  simple  analogy. 

Suppose  1  type  an  English  language  defmition  of  a  design  into  an  editor  using  ASCII  characters.  In  this  case,  the 
design  information  is  encoded  into  bits  in  a  file.  Not  only  is  there  a  great  deal  of  information  that  this  design  may 
express  that  is  not  in  the  file,  unless  I  know  that  the  data  is  expressed  in  ASCII,  even  its  meaning  as  characters  cannot 
be  communicated.  If  I  did  not  know  it  was  in  English,  another  essential  context  for  its  meaning  would  be  missing 
also.  Stated  more  generally,  data  by  itself  is  always  meaningless.  It  is  data  within  a  context  that  has  meaning.  In  the 
functional  perspective,  the  functions  that  can  be  applied  to  the  data  determine  la  large  extent  the  meaning  of  the  data. 

A  simplistic  solution  to  '-be  problem  of  exchanging  information  is  to  esublisli  a  universai  standard  for  the 
information;  effectively  create  a  universal  context  of  meaning.  In  the  above  example,  if  there  is  a  universal  standard 
that  tells  me  that  data  is  in  ASCII,  I  can  get  at  the  information  it  contains.  If  I  know  that  the  character  information  is 
VHDL  or  ADA.  I  can  get  more  information  out  of  it.  since  I  can  apply  a  larger  context  of  meaning  to  it.  if  this  context 
is  known  to  me.  However  as  we  remarked  before,  this  seems  to  be  a  hopeless,  and  even  undesirable,  approach  in  the 
case  of  design  systems.  Much  of  the  context  of  meaning  of  a  particular  design  environment  is  known  only  to  users 
familiar  with  it.  A  more  modest  approach  is  to  provide  a  methodology  for  establishing,  along  with  the  information, 
the  context  of  meaning  required  to  understand  it.  In  very  practical  form  and  in  a  limited  manner,  this  concept  has 
already  proven  its  use  on  the  Macintosh  system  I  am  using  to  type  this  paper.  First  the  system  assumes  some  widely 
known  context  of  meaning  necessary  to  perform  an  activity.  For  example  typing  text  on  a  regular  typewriter  is  such 
an  activity.  Such  a  known  activity  is  called  a  metaphor.  Then  the  system  attempts  to  recreate  that  activity  in  a 
manner  consistent  with  the  metaphor.  The  environment  required  to  display  the  character  data  and  manipulate  it,  that  is, 
the  aggregate  of  functions  used  to  edit  and  display  the  characters  in  these  sentences,  creates  the  metaphor  and  is  stored 
with  the  textual  data.  Whenever  the  textual  data  is  loaded,  its  context  is  assembled  and  also  loaded.  The  aggregate  of 
functions  used  to  manipulate  the  data,  to  create  its  context,  is  called  its  re.sources.  The  resources  establish  the 
meaning  of  the  data.  More  precisely,  the  resources  establish  a  bridge  to  the  context  of  meaning.  It  is  the  data  within  the 
context  of  the  functions  that  has  meaning.  This  is  a  simple,  yet  powerful  concept.  In  the  following  sections  we  will 
describe  a  similar  approach  to  the  description  of  design  information  that  seems  broadly  applicable  to  the  functional 
dimension  of  design. 

3.  Abstract  Functional  Resources 

There  is  a  growing  body  of  research  in  the  areas  of  programming  linguistics  and  software  engineering,  that 
suggests  a  method  for  resolving  some  of  the  difficulties  discussed  above  (Refs.  1 , 2,  3, 4, 5).  This  research  has  grown 
out  of  efforts  to  design  components  within  programming  languages,  and  subsequently,  within  general  software  systems. 
It  is  usually  called  the  theory  of  abstract  data  types,  although  at  the  present  time,  there  is  no  single  theory  but  rather  a 
methodology  that  is  evolving  to  handle  design  complexity  in  software  systems. 

There  has  been  a  realization  in  software  design  that  we  are  continually  re-implementing  the  same  functional 
resources  within  a  variety  of  environments  (Ref.  6.)  For  example,  the  part  of  a  software  system  that  accesses  files 
stored  on  a  disk  always  includes  functions  to  create,  open,  close,  read,  and  write  files.  Software  systems  may  perform 
these  functions  in  a  variety  of  ways,  but  in  some  abstract  sense,  they  all  perform  the  same  functions.  Substantial 
portions  of  software  system  design  consists  in  defining  a  hierarchy  of  functional  interfaces  of  greater  and  greater 
abstraction.  At  any  level  it  is  aggregates  of  functions  thata  define  the  resource.  For  example,  the  file  functions  above 
are  useful  only  as  an  aggregate.  Any  one,  without  the  others,  is  meaningless.  We  will  call  such  a  functional 
aggregate,  together  with  the  types  of  dala  it  manipulates,  a  resource.  Resources  ate  the  elements  of  functional  design. 
In  software  system  design,  we  would  like  to  have  a  way  to  precisely  describe  resources  absuactly,  without  regard  to  the 
specific  programming  language,  operating  system,  or  hardware  used  to  realize  them.  We  also  wish  to  establish  the 
ways  in  which  resources  combine  to  create  more  complex  resources.  We  would  like  to  describe  the  essence  of  these 
operations  in  a  manner  that  allows  us  to  reason  about  them  consistently.  This  would  be  a  step  toward  a  true  design 
theory  for  the  functional  dimension  of  systems  design.  The  primary  problem  to  be  solved  is  how  to  associate  meaning 
to  a  formal  description  of  a  resource.  How  do  we  insure  that  every  user  of  the  design  specification  interprets  its 
meaning  in  the  same  way?  Also,  if  we  wish  to  aid  the  designer  with  automated  tools  of  reasoning,  we  must  be  sure 
that  the  tools  manipulate  the  specification  in  meaningful  ways.  This  is  the  problem  of  specification  or  description 
semantics.  These  same  problems  arise  in  any  attempt  to  develop  an  automated  design  system,  and  in  any  attempt  to 
interface  or  integrate  systems.  It  seems  that  the  greatest  progress  in  this  direction  is  associated  to  the  theory  of  abstract 
data  types. 

There  are  several  features  in  this  theory  that  may  contribute  to  the  general  problem  of  integrating  and  interfacing 
design  systems: 
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Firstly,  the  approach  begins  with  an  attempt  to  solve  the  semantic  problem  for  design  components.  Not  only  is 
there  a  discipline  of  how  to  go  about  designing  components,  there  are  theories  associated  to  the  process  of  description 
that  provide  rigorous  meaning  to  design  components.  This  means  it  is  possible  to  automate  much  of  the  reasoning 
about  components  in  a  way  that  is  faithful  to  the  model  in  the  mind  of  the  designer. 

SecorxUy,  the  methodology  seems  to  be  very  general.  Although,  it  started  out  as  a  method  to  be  used  for  software 
functional  design  and  has  its  origins  in  programming  linguistics,  experiments  indicate  it  can  be  used  for  the  functional 
design  of  hardware.(Ref.  7,  8,  9,).  Since  it  has  crossed  these  boundaries,  it  holds  some  promise  as  a  basis  for 
interfacing  between  them. 

Thirdly,  it  is  an  abstract  methodology.  It  naturally  provides  a  method  of  design  that  is  independent  of  particular 
technologies  of  iiupiemenuuion.  In  software,  this  means  that  the  language  of  unplementation  is  not  a  necessary  issue 
during  design,  and  for  hardware,  it  means  that  the  manufacturing  technology  is  not  a  necessary  issue  of  design.  At  the 
same  time,  it  allows  issues  of  implementation  to  be  made  issues  of  design,  to  any  reasofiable  degree.  In  practice  the 
methodology  reflects  the  fact  that  abstract  objects  are  simpler  and  more  rarefied  and  thus  easier  to  define,  while  objects 
used  for  implementation  are  more  complex,  and  therefore  more  difficult  to  define.  Hence,  if  a  methodology  is  used  that 
forces  us  to  define  objects  precisely,  there  will  be  a  bias  towards  defining  them  in  their  most  essential,  abstract,  and 
thus  simplest  terms. 

At  the  present  time,  the  theoretical  work  on  abstract  data  types  has  been  focused  on  describing  components  suictly 
in  terms  of  the  functions  they  perform.  There  has  been  less  work  on  describing  the  temporal  properties  of  system 
components.  The  physical  properties  of  components,  such  as  size,  power  reqirements,  material  properties,  etc.  have 
yet  to  be  addressed  by  this  theory. 

This  theory  is  hierarchical  in  nature.  Design  components  can  be  described  in  terms  of  more  primitive  components. 
Fundamentally,  a  resource  is  described  by  listing  the  names  of  the  operand  types  it  requires,  and  the  operations 
(functions)  that  are  available  in  the  resource  to  manipulate  values  of  these  types.  As  we  have  indicated,  the  description 
is  a  purely  functional  one.  Each  operation  has  a  fixed  number  of  operands,  with  fixed  types,  and  a  fixed  reuim  type. 
The  operations  generally  include  functions  that  generate  the  primary  values  of  each  operand  type  (constant  functions). 
This  description  of  the  resource  defines  the  primary  functional  interface  to  the  resource.  Additional  parts  of  a  resource 
specification  describe  the  properties  of  the  resource,  and  ultimately  define  the  actual  meaning  of  the  resource  by 
application  of  an  associated  semantic  theory.  In  other  words,  the  semantic  theory  can  be  used  to  systematically 
determine  which  'real'  objects  provide  implementations  of  the  resource  defined  in  the  specification.  Error  conditions  can 
also  be  defined  in  the  specification  of  properties.  Although  much  of  the  flavor  of  this  approach  is  influenced  by  its 
development  from  software  design,  since  software  is  fundamentally  abstract ,  the  method  is  also  suited  for  expressing 
general  functional  resource  notions. 

4.  Resource  Specifications 

In  the  following,  we  will  take  a  brief  look  at  the  form  of  the  resource  specification  methodology.  A  more 
complete  treatment  can  be  found  in  the  literature  (e.  g.  Refs.  1,  3. 4,  10).  The  actual  syntax  for  specifications  is  not 
standardized,  although  most  variations  are  relatively  minor. 

Resource  objects  are  described  in  two  parts.  The  first  pan  is  the  syntactic  pan,  which  is  used  to  describe  a  forrri 
that  the  resource  can  take.  The  second  part,  the  semantic  pan,  is  implied  by  the  syntactic  pan. 

A  form  for  the  syntactic  part  is: 

Resource  [Resource  name]  is: 

Operand  Types: 

[Operand  type  set] 

Operators: 

(Operator  specification  set) 

Properties; 

[Property  specification  set] 
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The  operand  set  is  simply  an  unordered  list  of  names  for  the  operand  types  of  this  resource.  The  operator 
specincadon  set  is  an  unordered  list  of  the  names  of  the  operators  together  with  a  description  of  the  number  and  types  of 
their  operands  and  resulL  The  property  specificadon  list  is  a  list  of  properties  sadsfled  by  the  operators. 

For  the  purposes  of  illustradon,  consider  the  following  example  of  a  resource  specificadon  for  the  yes/no  resource. 

Resource  Boolean  is; 

Operand  Types: 

Bool 

Operators; 

True:  ->  Bool. 

False:  ->  Bool 
Not:  Bool  ->  Bool 
And:  Bool,  Bool  ->  Bool 

Properties; 

Not(TrueO)  =  FalseO. 

Not(Not(b))  =  b, 

And(TrueO.  b)  =  b, 

AndfFalseO.b)  =  FalseO 

Note  that  constants,  such  as  True,  and  False  above,  are  represented  as  nullary  operators  (or  equivalently,  constant 
funcdons). 

The  fundamental  idea  of  a  resource  specificadon  is  not  that  the  actual  resource  has  the  exact  form  given  in  the 
specificadon,  but  that  in  essence,  it  achieves  an  equivalent  funcdonality.  This  is  stated  precisely  in  the  accompanying 
semandcs  of  specificadons,  i.e.,  what  is  meant  by  the  above  syntax.  Without  going  into  the  semantics  in  detail,  let  us 
just  remark  that  it  is  a  consequence  of  the  semanuc  theory  associated  to  such  specificadons,  that  any  renaming  of  the 
above  operands  or  operators  above,  or  any  replacement  of  the  operators  by  equivalent  primitives,  such  as  not'  and 
'implies',  or  any  replacement  of  the  axioms  by  other  mathemadcally  equivalent  ones,  would  have  the  same  meaning. 
Thus  the  specificadon  above  is  only  one  of  many  descripdons  that  denotes  the  same  abstract  resource.  And  equally, 
the  abstract  resource  has  many  equivalent  realizadons,  or  implementations.  In  this  sense  then,  the  resource  description 
is  a  way  of  capturing  the  'abstract'  essence  of  the  resource. 

Boolean  is  a  primidve  resource.  It  is  not  built  up  of  more  primidve  elements.  It  is  atomic.  Specifications  can 
also  be  built  up  hierarchically.  To  illustrate,  consider  a  funcdonal  specificadon  for  a  stack  resource  that  can  hold 
boolean  values: 

Resource  Boolean_Stack  is: 

Extend  Boolean  with; 

Operands: 

Stk,  Bool. 

Operators: 

Mtstk:  ->  Stk 
Push:  Bool,  Stk  ->  Stk, 

Pop:  Stk  ->  Stk, 

Top:  Stk  ->  Bool. 

Properties: 

Top(Push(b,  s))  =  b 
Pop^ushfb,  s))  =  s 


Undefined(Top(MtstkO)) 

llndefined(PopWlsikO)) 
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The  extend  directive  can  be  interpreted  as;  "include  and  expand  the  named  specification  to  include  the  following 
operands,  operators,  and  properties."  Of  course,  when  a  resource  is  included  as  part  of  a  larger  resource,  in  the  context 
of  the  larger  resource,  its  properties  could  change.  In  the  above  example,  without  an  examination  of  the  properties  of 
Boolean_Stack,  we  can't  be  absolutely  sure  that  we  haven't  altered  the  properties  of  Boolean,  as  given  in  its 
specification.  (In  fact,  in  this  example,  it  isn't  difficult  to  check.)  A  resource  whose  properties  remain  unchanged 
within  a  larger  context  is  said  to  be  persistent'  in  that  context.  The  semantics  associated  to  specifications  provides  a 
systematic  way  to  check  for  persistence  and  exemplifies,  in  one  instance,  the  importance  of  rigor. 

Note  that  whenever  a  resource  is  specified  operations  in  addition  to  the  given  ones  are  implied  by  combinations  of 
the  given  ones.  For  example,  considering  only  the  Boolean  resource,  we  can  form  expressions  such  as: 

And(Not(TrueO).  Not(And(TrueO,  FalseQ))) 

In  general,  an  infinite  number  of  such  expressions  are  possible.  We  call  such  combinations  'formal  expressions', 
or  formal  terms'.  A  formal  grammar  can  be  written  for  these  formal  expressions  as  follows: 

<BoolTerm>  ->  TrueO  I 

FalseO  I 

Not(<BooITerm>)l 

And(<BoolTerm>.<BoolTeim>) 

Similarly,  the  Stack  resource  allows  us  to  create  more  expressions  in  addition  to  these  using  the  expressions  from 
the  Boolean  resource.  For  example,  if  vj,  V2. . . .  v„  are  Boolean  expressions,  then  the  following  expressions  illustrate 
formal  terms  from  the  Stack  resource. 

Push(vg.Push(v2,Pop(Push(v|  J>ush(v5.  MistkO))))) 

Push(Top(Push(v  I  .Push(vj,MtslkO))).  Push(v2.MlslkO) 

A  formal  LL(1)  grammar  can  be  written  for  these  additional  terms  by  extending  the  above  grammar  as  follows: 

<Term>  ->  <BoolTerm>  I 

<SlkTerm> 

<B(X5lTerm>  •>  Top(  <Stk  Tcnn>  ) 

<Slk  Term>  ->  MtstkQ  I 

Push(<  Boo\Term>  .  <Stk  Term>)  I 
Pop(<Stk  Term>) 

Thus  the  problem  of  recognizing  and  generating  all  correct  formal  terms  given  an  arbitrary  specification  is 
straightforward.  Note  we  require  that  there  is  at  least  one  constant  term  (nullary  term)  of  each  operand  type.  For  example 
TrueO  and  MtstkQ  are  the  constants  for  Bool  and  Stk.  Note  also  how  formal  expressions  are  created  on  top  of  the 
expressions  that  we  already  have  and  that  there  are  formal  terms  for  each  type  of  operand. 

Just  as  the  operator  list  is  a  finite  list  from  which  we  can  create  an  infinite  number  of  operations,  the  property  list 
is  a  finite  list  from  which  we  can  induce  an  infinite  number  of  properties,  which  are  in  fact,  relations  between 
operations.  Properties  effectively  specify  which  operations  have  an  equivalent  result.  The  precise  rules  for  deducing 
Such  relations  between  formal  terms  are  determined  by  the  semantics.  Although,  this  may  seem  to  be  a  simple  matter, 
it  is  a  more  difficult  problem  than  it  appears. 

In  Refs  /,  8.  9,  10  these  methods  for  describing  and  specifying  system  components  were  applied  to  the  design  of 
an  abstract  processor,  including  data  values,  memory,  and  instructions.  Subsequently,  the  same  methods  were  applied 
to  the  design  of  an  abstract  display  device,  and  database.  All  these  specifications  arc  of  course  functional.  Also,  they 
are  hierarchical.  The  abstract  processor  design  has  approximately  a  dozen  levels  and  hundreds  of  individual  functions. 
And  just  as  in  a  resource,  a  function  by  itself  may  not  have  meaning,  the  meaning  of  a  complex  resource  cannot  be 
separated  '■om  its  components.  Another  significant  feature  of  thc.se  designs  is  that  they  are  equally  applicable  to 
software  and  hardware.  In  fact,  the  abstact  processor  design  has  been  implemented  in  software  (Ref.  1 0).  We  can  now 
clarify  how  it  is  possible  to  establish  the  context  of  meaning  required  to  understand  information  about  a  particular  part 
of  a  design,  without  requiring  a  standard  means  of  expression. 
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In  the  designs  that  use  the  methodology  just  described  ,  the  meaning  of  part  of  the  design  is  determined 
precisely  by  two  factors.  Firstly,  there  is  the  general  semantics  that  is  part  of  the  context  of  the  specification 
methodology  itself.  Secondly,  there  is  the  context  of  elements  in  the  specification  that  are  specifically  related  to  the 
element  of  interest.  One  is  the  universal  context  of  meting  that  is  to  be  applied.  The  other  is  the  private  context  of 
meaning  that  is  relevant  to  a  particular  item  in  the  context  of  its  design.  In  the  abstract  processor  design  referenced 
above,  the  context  of  meaning  for  a  specific  machine  instruction  or  feature  of  the  processor,  can  be  rigorously 
determined.  With  this  type  of  approach  to  the  description  of  design  elements,  the  contexts  that  are  necessary  to  establish 
the  meaning  of  any  information  in  the  design  can  be  readily  determined.  Yet,  there  is  no  standard  representation  of  any 
particular  element  in  the  design.  (For  example,  the  Boolean  resource  may  have  been  represented  differently).  1  here  is 
also  no  standard  way  that  elements  must  be  combined.  (Different  elements  may  be  combined  in  many  ways  to  achieve 
the  same  functional  result).  Yet,  we  have  indicated  drat  there  can  be  a  standard  methodology  of  description  and 
semantics  that  allows  us  to  determine  the  meaning  of  something  no  matter  how  it  is  expiessed.  It  is  this  kind  ol 
approach  to  the  problems  of  design  system  integration  and  interfacing  that  we  are  suggesting. 

Another  way  of  expressing  the  same  result,  is  that  there  need  to  be  standardized  methodologies  crossing  system 
design  boundaries  that  provide  a  capability  for  systematically  understanding  design  information  from  one  system  inside 
another,  even  though  the  two  systems  may  support  different  views,  and  different  technologies  of  design. 

S.  Concluding  Remarks. 

We  have  raised  a  number  of  points  that  relate  to  the  problems  of  interfacing  or  integrating  a  variety  of  design 
systems.  The  semantic  issue  includes  the  problems  that  arise  when  there  is  a  gap  between  what  a  component  is  in  a 
system  compared  to  what  it  is  in  the  mind  of  a  us^t  of  the  system.  Interface  difficulties  will  remain  as  long  as  serious 
semantic  gaps  remain.  We  have  suggested  that  the  meaning  of  information  in  a  design  system  can  be  represented  to 
some  extent  in  the  system,  but  always  includes  elements  in  a  broader  context  of  meaning.  We  have  also  suggested  that 
universal  standards  of  description  for  design  information  seem  premature,  although  some  methodological  standards  may 
be  possible.  In  particular,  a  standardized  semantic  methodology  for  design  descriptions  that  crosses  system  boundaries 
seems  to  be  a  reasonable  alternative.  In  general,  greater  attention  to  issues  of  semantics  and  contexts  of  meaning  seem 
warranted. 

For  the  functional  dimension  of  design,  we  have  indicated  the  importance  of  the  concept  of  a  resource.  We  have 
also  suggested  that  a  theoretical  basis  for  a  general  theory  of  functional  design  that  can  cross  applicauon  boundaries  is 
within  our  grasp.  Although,  such  a  prospect  seems  reasonable  in  the  functional  dimension,  fundamental  problems  in 
the  physical  and  temporal  dimensions  remain.  There  are  as  yet  no  widely  accepted  notions  of  ihc  general  meaning  of 
concurrency  and  communication.  There  is  certainly  no  acceptable  semantic  context  for  these  notions,  although  there  are 
several  efforts  in  this  direction 

Finally,  we  suggest  that  more  attention  be  paid  to  fundamentals.  There  is  an  ever  increasing  need  for  broader 
perspectives  on  the  design  process,  and  movement  away  from  ad-hoc  methods. 
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K.DeSipio.  US 

It  is  difficult  to  communicate  with  words  because: 

•  Words  change  meaning  relative  to  culture/  education. 

•  Fads  come  from  the  top:  trends  come  from  the  hoiiom. 

Please  comment. 

Author's  Reply 

Methodologically,  we  need  to  acknowledge  the  importance  of  the  semantic  conic.vis  that  give  meaniiig  to  words  and 
diagrams  (i.e.,  forms  of  expression).  I  generally  agree  that  fads  come  from  the  top  and  trends  from  the  boitom 

Successfully  shared,  precise  semantic  contexts  do  exist.  This  is  what  mathematics  is  all  about.  Can  we  de\  clop  some 
rigorous  semantic  context  for  design  (i.e..  a  design  science)’.’  Would  anyone  advtKatc  that  we  can  do  cngineeiing 
without  mathematics? 


W.H.McKinlay,  UK 

What  van  we  learn  from  the  personal  qualities  and  styles  oi  successful  engineers,  and  what  ate  the  implications  h'r 
education? 

Author's  Reply 

The  unquantifiable  characteristics ^»f  successful  citgineers  arc  something  we  really  cannot  seem  to  address,  ('an  we.  on 
the  other  hand,  address  fundamental  design  principles  that  apply  broadls  and  quit  rediscovering  them  over  and  over .’ 
We  can  sense  that  such  principles  must  exist,  but  what  are  they,  and  how  can  they  be  e.xpressed  and  become  general 
knowledge?  There  is  still  no  substitute  for  creative  engineering. 
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SUMMARY 

Two  important  issues  exist  in  addressing  the  solutions  to  future  avionics  systems 
development  problems:  avionics  systems  training  for  both  designers  and  testers,  and  the 
avionics  systems  development  process  itself.  The  airborne  avionics  training  and 
integration  laboratory,  such  as  the  USAF  Test  Pilot  School's  Avionics  Systems  Test 
Training  Aircraft  (ASTTA),  may  be  a  potential  remedy  for  some  of  the  underlying  problems 
of  avionics  systems  development. 

ASTTA  is  a  special  configuration  of  the  NC-131H  Total  In-flight  Simulator  (TIPS),  and 
was  developed  to  fill  a  significant  gap  in  the  education  and  experience  of  the  avionics 
systems  test  community.  It  provides  a  cost-effective  means  of  quickly  exposing  both 
designers  and  testers  to  the  key  issues  of  systems  development  and  in-flight  testing, 
especially  the  operator  to  systems  interface  human  factors  issues.  Its  benign  flight 
environment  is  conducive  to  both  initial  and  advanced  training  in  flight  test  techniques. 

ASTTA  offers  exciting  potential  as  a  test  bed  for  a  large  variety  of  research  and 
development  activities.  Proof-of-concept  testing  is  particularly  attractive  with  minimum 
packaging  required  of  teat  devices  and  the  ability  to  carry  several  observers  and  even  the 
designers  themselves . 


INTRODUCTION 

The  future  development  of  complex  avionics  systems  is  in  the  hands  of  two  groups  of 
people  -  the  designers  and  the  testers  1  In  the  past,  these  groups  have  generally 
performed  as  separate  entities;  their  viewpoints  of  the  ultimate  operational  user’s 
environment  and  functional  needs  have  often  been  inaccurate.  Avionics  systems  have  been 
developed  and  deployed  which  were  unusable  by  the  operators  due  to  unacceptably  high 
workloads.  Avionics  systems  have  been  rushed  into  testing  and  operational  use  without 
adequate  functional  integration  and  simulation  with  operator-in-the-loop  evaluation. 

Though  the  situation  is  slowly  improving,  problems  still  exist.  Two  important  issues 
exist  in  addressing  the  solutions  to  these  avionics  systems  development  problems: 
avionics  systems  training  for  both  designers  and  testers,  and  the  avionics  systems 
development  process  itself.  These  Issues  are  the  focus  of  this  paper.  They  are  also  the 
underlying  reasons  behind  the  development  of  the  USAF  Test  Pilot  School's  Avionics  Systems 
Test  Training  Aircraft  (ASTTA).  ASTTA  will  be  used  as  an  example  of  a  tool  to  potentially 
remedy  some  of  the  problems  in  avionics  systems  development. 

Both  the  designers  and  testers  of  avionics  systems  are  often  limited  in  the  scope  and 
breadth  of  their  training,  knowledge,  and  experience.  Avionics  systems  designers  do  their 
work  in  the  serenity  of  their  office  or  laboratory,  with  limited  attention  paid  to  the 
practicalities  demanded  by  the  operational  environment.  Testers  are  equally  guiltyl  The 
testers  are  highly  proficient  in  performance  and  flying  qualities  flight  test  techniques, 
but  often  lack  avionics  systems  test  training.  They  remember  the  cliche  for  avionics 
systems  testing  -  "you  must  invent  your  own  flight  test  techniques."  Too  often  they  step 
into  the  cockpit  unprepared  and  unaware  1 

The  avionics  systems  development  process  itself  may  also  be  the  source  of  a  problem. 
Designers  develop  systems  that  work  well  individually  and  appear  to  integrate  adequately 
on  paper  and  in  the  laboratory.  The  fact  that  a  human  operator  is  part  of  the  operational 
system  is  often  forgotten  during  the  functional  development  of  "black  boxes"  and  iuring 
their  integration  into  a  highly  flexible  system.  Too  much  flexibility  can  become  detri¬ 
mental  when  it  causes  excessive  demands  on  operator  dexterit/  and  mental  capacity.  The 
designs  must  accommodate  tactical  system  operators  working  in  a  strenuous  environment,  not 
computer  wizards  or  video  game  players.  Often  ground  verification  testing  and  functional 
ground  simulation  are  quickly  followed  by  full  up  flight  test  in  the  vehicle  with  little 
or  no  ground-based  operator-in-the-loop  integration  testing.  The  result  is  a  costly 
fly-Cix-fly  schedule  that  progresses  at  a  snail's  pace. 

The  concurrent  integration  of  the  ARN-lOl  avionics  update  and  the  PAVE  TACK  weapons 
system  to  the  USAF  F-4  was  an  example  of  the  type  of  integration  problems  one  would  like 
to  avoid.  The  simultaneous  integration  of  these  two  systems  to  the  F-4  lacked  the 
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required  integration  to  each  other.  The  result  was  integration  flight  testii.g  as  opposed 
to  developmental  flight  testing. 

The  F-16  Multistage  Improvement  Program  (MSIP)  with  Block  25  avionics  is  another 
example  of  a  process  that  resulted  in  a  system  that  was  not  tailored  to  th--  flight 
environment  and  fostered  operator  errors.  As  an  example,  it  was  common  for  the  pilot  to 
have  changed  his  radio  frequency  inadvertently  two  to  three  times  before  takeoff. 

Consider  what  could  happen  in  combat  if  a  pilot  could  not  transmit  on  the  radio  to  his 
wingman.  The  development  of  the  Block  25  systems  was  done  in  system  integration 
laboratories  which  tested  only  individual  black  boxes.  The  result  was  a  good  i ’ea  poorly 
implemented  and  unsuitable  for  a  production  aircraft.  As  a  result  of  serious  d  Mciencies 
uncovered  during  flight  test,  it  was  necessary  to  remechanize  the  avionics  nrior  tn 
production  (Block  25B). 

These  two  situations  were  the  pro<iuct  of  a  process  that  produced  an  operationally 
usable  system  only  after  considerable  developmental  problems  were  solved.  Consider  tho 
advantage  of  aiiding  an  airborne  simulation  laboratory  to  the  development  process  as  shown 
in  Figure  1.  One  may  see  a  practical  advantage  but  question  the  cost  and  scheiuling 
aspects.  To  put  these  considerations  in  proper  perspective,  one  must  evaluate  the 
tradeoff  between  cost  and  schedule  problems  of  using  such  an  airborne  testb'^.i  versus 
developmental  risk  as  shown  in  Figure  2- 


Figut'-  1.  -  Avionics  Systems  t/<?ve  1< ‘pment  Pr  Hres.s 
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Figure  2-  -  Airborne  Simulation  Fidelity  Assessment 
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The  fidelity  with  which  such  an  airborne  simulation  laboratory  represents  the 
operational  environment  is  also  a  critical  concern.  High  fidelity  of  environment  simula¬ 
tion  (approaching  100  percent)  may  require  an  exact  test  vehicle  which  may  not  exist  when 
you  need  it  or  may  be  prohibitively  costly  and/or  schedule  prohibitive.  On  the  other 
hand,  a  lower  fidelity  simulation  (60  to  70  percent  for  argument’s  sake'  may  suffice  for 
proof-of-concept  evaluation,  and  integrate  the  operator  in  a  relatively  realistic 
environment  at  an  early  stage  and  for  significantly  lower  coat.  The  question  is:  What 
fidelity  of  simulation  is  acceptable  for  developmental  assessment?  An  airborne  environ¬ 
ment  simulation  with  the  knee  of  the  curve  (in  Figure  2)  as  its  target  may  serve  as  the 
best  compromise  between  risk  and  cost/schedule,  and  hence  may  be  the  beat  approach  to 
proof-of-concept  testing  and  airborne  simulation. 

Ultimately,  the  avionics  systems  package  must,  be  tested  in  the  vehicle  for  which  the 
package  is  being  developed.  However,  many  of  the  new  state  of  the  art  systems  are  being 
developed  for  new  tactical  vehicles  which  themselves  are  under  development.  This  leads  to 
a  dilemma  about  the  timeliness  of  avionics  systems  testing  in  the  flight  test  vehicle. 

The  "build-up  technique"  is  the  classical  approach  to  flight  test  of  a  new  vehicle  and  its 
systems.  Performance,  flying  qualities,  and  clearance  of  the  structural  flight  envelope 
initially  take  precedence  over  systems  testing,  and  rightly  so  to  some  extent.  However, 
cost  and  time  effective  development  of  complex  avionics  systems  requires  the  interjection 
of  dedicated  systems  development  test  and  evaluation  (DT&E)  and  initial  operational  te£,t 
and  evaluation  (lOTiE)  testing  earlier  in  the  flight  test  sequence  than  has  generally  been 
the  case. 

Lack  of  timely  operator-in-the-loop  simulation  and  in-flight  testing  has  caused  many 
avionics  development  scenarios  to  evolve  as  follows.  First,  the  testers  "curse"  the 
designers  for  a  system  that  fails  to  perform  adequately  in  the  airborne  arena  or  performs 
adequately,  but  with  an  intolerable  workload.  Next,  the  operational  users  "curse"  the 
testers  for  recommending  changes  to  the  integrated  system  that  either  they  do  not  want  or 
which  will  not  work  in  the  operational  environment,  or  which  fails  to  consider  the 
man-machine  interface  at  the  lowest  common  denominator  -  the  new  second  lieutenanti  The 
designers  retaliate  with  solutions  to  all  these  claims,  but  at  the  expense  of  the 
managers'  cost  and  schedule.  The  managers  respond:  Is  it  safety  related?  If  not,  forget 
it!  This  vicious  cycle  continues  until  initial  operational  capability  (IOC). 

Until  recently,  few  solutions  have  been  proposed  to  alleviate  these  developmental 
headaches.  About  two  years  ago,  the  USAF  Test  Pilot  School  sponsored  the  development  of 
the  ASTTA  training  and  facility  to  help  resolve  some  of  the  problems  we  have 

outlined.  The  introduction  of  the  ASTTA  facility,  we  submit,  represents  an  important  step 
in  the  right  direction,  though  not  a  remedy  for  all  our  avionics  development  problems. 

ASTTA  was  developed  primarily  to  fulfill  the  training  requirements  of  the  USAF  Test 
Pilot  School  in  the  avionics  systems  flight  test  environment,  i.e.,  train  the  testers. 

The  evclution  of  ASTTA  concentrated  on  its  objectives  of  being  a  familiarisation, 
demonstration,  and  evaluation  tool  for  avionics  systems  development  for  our  Test  Pilot 
School  pilots,  flight  test  engineers,  and  flight  test  navigators. 

ASTTA  CAPABILITIES 

ASTTA  is  a  new  configuration  of  the  USAF  Plight  Dynamics  Laboratory’s  NC-131H  Total 
In-flight  Simulator  (TIFS)  six  degree  of  freedom  variable  stability  aircraft  which  has 
been  in  research  and  development  (R&D)  operation  since  1971.  Figure  3  shows  the  two 
different  configurations  of  the  NC-131H  aircraft.  Calspan  Corporation  of  Buffalo,  Hew 
York,  developed  ASTTA  under  contract  with  the  USAF.  The  ASTTA  configuration  has  the 
following  capabilities  and  limitations:  test  airspeeds  between  160  and  250  knots 
indicated  airspeed  (KIAS),  altitudes  between  500  feet  above  ground  level  (AGL)  and  10,000 
feet  mean  sea  level  (MGL)  except  for  landing  evaluations,  normal  acceleration  from  0  to 
2.5  gs,  sustained  turn  rates  of  12  degrees  per  second,  fuel  for  a  nominal  2  hour  mission, 
and  full  instrument  flight  rule  (IFR)  capability. 

ASTTA  can  carry  five  systems  evaluators  in  addition  to  the  two  Calspan  safety  pilots 
and  systems  engineer.  The  systems  evaluation  crew  station,  which  is  just  aft  of  the 
propeller  line  of  the  aircraft  as  shown  in  Figure  4,  has  dual  seats  with  standard  IFR 
flight  instruments  in  addition  to  radar,  infrared  (IR),  and  inertial  navigation  system 
(INS)  controls  and  displays.  An  instructor  jump  seat  has  been  provided  between  and  aft  of 
the  crew  station  seats  along  with  two  observer  seats  further  aft  in  the  cabin. 

The  avionics  systems  on  ASTTA  include  the  Westlnghouse  APG-66  digital,  multimode, 
pulse  doppler  radar  from  the  F-16A/B  (Figure  5):  the  Texas  Instruments  AN/AAS-36  infrared 
detecting  set  (ir.DS)  from  the  P-3  aircraft  (Figure  6):  the  commercially  available  Litton 
LTN-72R  INS  (Figure  7);  a  slewable  platform  with  a  color  camera  which  is  mechanically  and 
functionally  interchangeable  with  the  IROS  (Figure  8);  and  an  interface  computer  with 
associated  software  allowing  the  integrated  operation  of  thes^  sensors.  The  integrated 
operation  of  the  ASTTA  sensors  include  the  ability  to  slave  either  the  radar  or  IRDS  to 
the  other  in  the  radar  air-to-air  mode  or  the  ability  to  slave  the  IRDS  to  the  radar  in 
the  radar  air-to-ground  mode.  The  independent  operation  of  each  sensor  allows  concurrent 
side-by-side  training  and  testing  c  each  system. 

The  ASTTA  multiplex  (MUX)  bus  structure  is  shown  in  Figure  9.  The  Interface  Covitrol 
Unit  (ICU)  acts  as  the  MIL-STD  1553  data  bus  controller  for  the  integrated  system  (Figure 
10).  The  radar  digibus  is  the  primary  radar  controller.  At  the  present  time,  three  ports 
on  the  bus  are  not  utilized  and  thus  could  be  used  for  the  addition  of  new  systems. 


Figure  3a.  -  TIPS  Configuration 


Figure  3b.  -  ASTTA  Configuration 


Figure  4.  -  ASTTA  Systems  Evaluation  Crew  Station 


Figure  5. 
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Figure  9.  -  ASTTA  Multiplex  Bus  Structure 
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Figure  10.  -  Functional  Diagram  of  the  Integrate'^  Sensor  Systeiii 

Tue  systems  engineer  station  (Figure  11)  is  the  primary  station  for  monitoring  and 
control  of  the  aircraft  electrical  and  cooling  as  well  as  all  data  recording  systems.  The 
data  recording  capabilities  of  ASTTA  include:  Video  Home  System  (VHS)  recor<3ers  for  the 
radar  display  (525  lines)  and  high  resolution  IRDS  display  (875  lines),  for  an  over-the- 
shoulder  camera  pointed  at  the  ASTTA  crew  station,  and  for  a  forward-looking  video  camera 
in  the  safety  pilot  cockpit  for  situational  awareness  at  the  ASTTA  crewstation;  a  Jonos 
microcomputer  connected  to  either  the  ICU  or  the  radar  digibus  with  the  capability  to  read 
out  any  8  param*='ters  for  display  on  a  strip  chart  recorder  or  for  storage  on  a  58  channel 
digital  recorder;  a  complete  set  of  aircraft  state  parameters  from  the  variable  stabil’ty 
system  (Figure  12)  instrumentation  (also  on  the  58  channel  digital  recorder):  voice 
recording  on  all  VHS  recorders;  ground  radar  tracking  and  positioning  using  a  C-band 
beacon  transponder;  and  time  code  correlation  of  all  data  through  an  TRIG  a  format  Lime 
code  generator,  v'ideo  inser^-ion  unit,  and  cockpit  display.  Telemetry  is  planned  for  the 
near  future.  The  ASTTA  data  recording  schematic  is  shown  in  Figure  13. 

With  a  ’’ riy-by-wire  ”  stick  tlie  capability  to  fly  from  ei  Lher  seat 

(Figure  14),  ASTTA  offers  aircrews  a  realistic  operator  workload  in  a  "benign"  airborne 
environment.  This  "benign"  environment  includes  "time  expansion"  and  a  Low  g  environment 
which  are  actually  advantageous  for  training  purposes  and  for  initial  DT6E.  When 
required,  sufficient  closure  rates  can  be  generated  with  the  proper  choice  of  high  speed 
targets.  The  ASTTA  aircraft  can  sustain  turn  rates  comparable  to  400  KIAS/Sg  conditions- 
The  variable  stability  system  can  be  used  to  generate  direct  lift,  direct  side 
translation,  turbulence,  and  other  environmental  conditions. 
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Figure  13*  -  ASTTA  Data  Recording  Schematic 
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USAF  ASTTA  TRAINING  CURRICULUM 

The  USAF  Test  Pilot  School's  approach  to  avionics  systems  test  training  is  systematic 
and  structured  yet  flexible  to  the  individual  atudetic’s  prior  education  and  experience. 

The  ASTTA  training  program  is  in  three  phases:  ground  training  in-flight  test  training, 
and  reporting,  as  detailed  in  Table  1. 

Ground  training  includes:  classroom  academics  on  avionics  systems  and  their 
integration,  human  factors,  and  ASTTA  operating  procedures:  laboratories  dedicated  to 
demonstrating  flight  test  techniques;  and  discussion  of  flight  test  techniques  describing 
the  in-flight  maneuvers  and  data  gathering  procedures-  This  is  followed  by  groi^jjd 
familiarization  time  with  the  ASTTA  systems  prior  to  flight.  One  major  advantage  designed 
into  ASTTA  is  that  many  of  the  flight  test  techniques  can  be  demonstrated  on  the  ground 
with  all  syatemti  po'»»ered  up  using  ground  and  airborne  targets  of  opportunity.  A  weight- 
on-wheels  override  switch  allows  operation  of  all  ASTTA  systems  on  the  ground  with  only 
the  use  of  external  power.  Experience  has  shown  that  ground  run  time  is  limited  by  the 
endurance  of  the  operators  and  not  the  systems. 


Academics 

Laboratory 

Flight  Test  Techniques 

Fami liarization 

Human  Factors 

6.0 

_ 

- 

Electro-Optics 

8.0 

1 . 5 

2.0 

- 

Radar 

11. 0 

1.5 

1.0 

- 

ECM/ECCH 

3.0 

- 

- 

- 

TNS 

9.0 

- 

1.0 

- 

Avionics  Integration 

7.0 

- 

- 

- 

ASTTA  Procedures 

2.0 

- 

1.0 

1.0 

Total  Hours 

46.0 

3.0 

5.0 

l.O 

In-flight  Test  Training 


Flight  #1  (day) 


-  Air-to-air  radar,  air-tc»-qround  radar,  IR,  INS,  avionics 
integration,  human  factors,  and  operational  navigation  route 


Flight  #2  (night) 


Air-to-ground  radar,  IR,  INS,  avionics  integration,  and  human 
factors 


2.0 


2.0 


Flight  #3 


-  Optional  (same  profiles  as  flight  #2  or  #3) 


2.0 


Daily  Flight  Report 
Group  Oral  Report 


Reporting 

Hours 

as  required 
1.0 


Table  1.  -  USAF  Test  Pilot  School  ASTTA  Training  Program 


In-flight  testing  includes  preflight  and  postflight  ground  tests  to  verify  contractor 
laboratory  data;  in-flight  teste  of  radar,  IRDS,  INS,  and  sensor  integration;  and  the 
evaluation  of  pertinent  human  factors.  Table  2  presents  a  partial  list  of  in-flight  test 
training  areas  performed  during  student  training. 

In  the  reporting  phase,  students  are  taught  to  accurately  report  what  they  saw  and  to 
make  recommendations  to  fix  problem  areas.  Mission  suitability  is  always  the  primary 
objective.  Daily  flight  reports  summarize  each  mission.  The  final  oral  report  includes  a 
summary  of  findings  and  recommendations  from  all  student  training  missions.  A  question 
and  answer  period  on  the  oral  report  and  systems  test  knowledge  completes  the  ASTTA  pha«»o 
of  training. 

The  avionics  systems  training  process  as  not  complete  with  ASTTA,  but  is  only  begun. 
Students  perform  numerous  other  systems  evaluations  on  aircraft  such  as  the  A-6,  A-7D, 
A-7K,  E-2C,  F-4  ARN-lOl,  F-4G,  RF-4C,  F-14,  P-15,  F-16,  F-18,  F-lll,  P-3,  S-3,  and  T-43. 
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Syste.'Ti 


In~flight  Tests 


Air-to-air  radar 


Air-to-ground  radar 


Infrared  Detector 
Set 


Inertial  Navigation 
Set 

Human  Factora 


-  Maximum  detection  range;  minimum  and  maximum  lock-on  range  at 
varying  aapecta  and  look-up  or  look-down;  time  to  stable  track: 
elevation,  range,  and  azimuth  resolution;  track-through-the-notch 
evaluation;  Air  Combat  Mode  evaluation;  and  mission  suitability 

-  Minimum  and  maximum  detection  range/  range  and  azimuth  resolution, 
ranging  accuracy,  display  accuracy,  Doppler  Beam  Sharpening 
evaluation,  radar  low  level  navigation,  and  mission  suitability 

-  Viewing  distance;  static  and  dynatr’*'*  resolution;  slew  rates  and 
limits;  tactical  target  detection,  recognition,  and 
identification;  IR  low  level  navigation;  and  mission  suitability 

-  Position  error,  circular  error  probable,  INS  low  level  navigation, 
and  mission  suitability 

-  Control  and  display  mechanization  and  compatibility,  illumination, 
atmospheric  conditions,  noise,  procedural  sequence,  crew  station 
accommodations,  ingr^ss/egress,  and  mission  suitability 


Avionics  Integration  -  Radar,  IRDS,  and  INS  air-to-air  and  air-to-ground  integration,  and 
mission  suitability 


Table  2.  -  In-flight  Test  Training  Areas 


USE  OP  ASTTA  FOR  SPECIAL  PROJECTS 


A  logical  adjunct  to  the  process  of  training  students  in  flight  test  techniques  on  the 
ASTTA  aircraft  was  the  initiation  of  an  advanced  systems  evaluation  project.  The  first 
such  test  project  took  place  in  the  fall  of  1986  with  a  dedicated  systems  engineer  group- 
The  in-flight  task  included  independent  and  integrated  operation  of  the  sensors  while 
simultaneously  flying  the  ASTTA  aircraft  via  its  fly-by-wire  system  during  air-to-air 
intercepts,  and  day  and  night  low  level  navigation  routes.  The  pilot  was  fitted  with 
physiological  instrumentation  to  yield  electroencephalograms  (EEG)  as  shown  in  Figure  15. 
The  objective  of  this  project  was  to  correlate  the  pilot’s  subjective  assessment  of 
workload  in  the  in-flight  tasks  using  avionics  test  modified  Cooper-Harper  ratings. 
Subjective  Workload  Analysis  Technique  (SWAT),  and  pilot  comments;  to  the  objective 
measures  of  workload  including  EEG,  analysis  of  pilot  control  activity,  and  of  deviations 
from  the  specified  altitude  and  heading  profiles.  This  effort  was  in  support  of 
continuing  research  in  developing  objective  metrics  of  pilot  workload  for  use  in 
optimizing  pilot-system  interfaces. 


Figure  15.  -  Pilot  Wired  with  Physiological  Instrumentation  (Left  -  Preflight, 
Right  -  In-flight) 


It  is  in  the  interest  of  the  USAF  Test  Pilot  School  to  continue  and  expand  this  kind 
of  utilization  of  the  ASTTA  platform  for  special  projects  conducted  by  the  students  as 
practical  application  of  their  systems  training.  Besides  giving  the  students  valuable 
additional  hands-on  test  experience,  such  projects  serve  to  develop  systems  test 
luanagement  skills.  There  is  a  varied  scenario  of  R&D  activities*  (see  ASTTA  as  an  Airborne- 
Systems  Integration  Test  Bed)  being  contemplated  as  an  evolution  of  the  current  ASTTA 
system,  which  will  readily  serve  as  the  basis  for  future  student  projects. 

MULTI-USER  FACILITY 

The  ASTTA  aircraft  is  a  IJSAF  asset  available  for  training  and  RiD  utilization  by 
qualified  agencies  or  organizations.  Utilization  of  ASTTA  has  evolved,  in  the  short  time 
since  its  conception,  from  its  original  objective  of  training  USAF  Test  Pilot  School 
personnel  to  familiarization  and  training  of  other  Department  of  Defense  (DOD)  and 
contractor  testers  and  designers.  The  US  Maval  Test  Pilot  School  is  using  the  aircraft 
for  avionics  systems  test  training  of  their  test  pilots,  engineers  and  Naval  Flight 
Officers  (NFOs);  the  Air  Force  Flight  Test  Center  is  using  ASTTA  for  initial  and 
continuation  training  for  its  avionics  engineers;  and  Air  Force  personnel  from  other  bases 
such  as  Wright-Patterson  AFB,  Ohio  and  Palmdale  Air  Force  Plant  42,  California,  have 
trained  on  ASTTA.  One  such  training  session  was  dedicated  to  optical  system  test 
techniques  and  was  ii*c;trumental  in  the  testing  of  a  new  optical  system  for  the  USAF. 
Contractor  engineers  have  flown  on  the  aircraft  on  a  noninterference  basis  as  observers. 
Future  dedicated  contractor  training  flights  are  contemplated  witli  the  concurrence  and 
support  of  their  Air  Force  sponsor? 

ASTTA  AS  AN  AIRBORNE  SYSTEMS  INTEGRATION  TEST  BED 

Due  to  its  size,  modular  design,  and  extensive  instrumentation,  ASTTA  offers  unique 
opportunities  for  low  cost  in-flight  test  and  evaluation  of  new  avionics  systems,  and  in 
particular,  of  the  interface  between  the  systems  and  operators  (i.e.,  the  human  factors 
issues).  Large  pieces  of  equipment  and  large  systems  may  be  tested  in  a  roomy  environment 
with  designers  looking  over  the  shoulders  of  the  testers  or  designers  doing  the  testing 
themselves.  "Tweaking*'  of  avionics  equipment  while  airborne  is  a  big  advantage  of  this 
aircraft.  Candidate  systems  for  incorporation  in  the  near  term  include  a  Global 
Positioning  System  (GPS)  to  supplement  the  INS  for  position  information  with  the  accuracy 
required  for  new  navigation  systems  evaluations  and  ca 1 ibrat ions ,  and  a  Ground  Proximity 
Warning  System  (GPWS).  High  on  the  list  of  priorities  for  interface  testing  are  head-up 
display  (HUD)  an'",  head  down  multifunction  display  (MFD)  formats  mixing  flight  status  and 
tactical  sensors  information  in  a  manner  which  optimize  the  displays  for  specific  piloting 
tasks.  Flat  plate  dot  matrix  display  evaluations  are  being  planned  for  the  near  future. 

A  modular  "design-a-cockpit"  concept  with  rapid  configuration  changes  will  allow  cockpit 
design  studies,  along  with  voice  activated  control  studies,  and  unusual  attitude  studies 
using  conventional  attitude  information  and  new  approaches  to  the  spatial  disorientation 
problem  such  as  the  Malcolm  horizon.  Furthermore,  with  color  display  hardware  integrated, 
"pathway-through-the-sky"  can  be  presented  to  the  pilot  giving  threat  avoidance  guidance 
which  he  would  "fly"  via  the  fly-by-wire  controls.  Effective  presentation  of  information 
continues  to  be  a  dominant  Issue  in  operator-in-the-loop  system  development. 

Testing  of  system  manipulators/controllers  can  be  performed  in  a  realistic  in-flight 
scenario  with  an  appropriate  turbulence  environment,  either  natural  or  generated  through 
ASTTA's  variable  stability  system.  These  tests  can  be  performed  in  a  fully  instrumented 
environment,  with  the  pilot/operator  instrumented  with  extensive  physiological  sensors; 
while  data  recorders  monitor  the  avionics  systems,  the  aircraft  flight  parameters,  and  the 
pilot's  control  activity.  This  should  also  provide  a  valuable  facility  to  test  various 
proposed  workload  reducing  features  of  the  pilot-system  interface  in  highly  demanding 
missions  using  the  single  seat  night  attack  fighter  scenario  as  the  reference  critical 
bench  mark.  For  example,  proof-of-concept  testing  of  pilot  associate  or  expert  system 
devices  could  be  performed  cost  effectively  in  a  realistic  environment. 

Although  ASTTA's  Jonos  minicomputer  port  on  the  radar  digibus  is  currently  pa'^aive 
'data  retrieval  only),  the  software  can  be  modified  to  permit  on-line  variation  of  radar 
operating  characteristics  for  training  and  RiD  purposes.  By  flying  AS'?  TA  over  radar  test 
ranges,  ECM/ECCM  testing  can  performed.  Alternatively,  using  a  data  link  to  ground  based 
computers  simulating  realistic  electromagnetic  threat  environments,  radar  performance  can 
be  evaluated. 

Modification  of  the  ASTTA  system  bus  architecture  to  include  a  separate  1553  avionics 
data  bus  will  facilitate  rapid  on-line  integration  of  new  systems  or  sensors.  This  will 
also  permit  interaction  with  the  existing  basic  aircraft  flight  control  system  1553  bus  to 
permit  study  of  flight  control/fire  control  integration  issues.  The  current  ASTTA  nose 
with  its  complement  of  sensors  can  be  replaced  with  a  mimic  nose  housing  another  set  of 
sensors,  thereby  permitting  testing  of  a  variety  of  sensor  combinations  and  their 
integration  features  as  shown  in  Figure  16.  The  aircraft  could  also  accommodate  external 
sensor  pods  such  as  the  AGM-65D  Maverick,  Low  Altitude  Navigation  and  Targeting  Infrared 
for  Night  (LANTIRN),  or  other  new  sensor  pods,  mounted  under  the  nose  area. 

other  potential  test  bed  applications  include:  tests  of  artificial  intelligence 
devices,  tactical  sensor  software  development,  tests  of  reprogrammed  software  of 
operational  systems  using  the  US  DOD  ADA  programming  language,  optical/IR  sensor 
evaluations  on  a  slewable  electro-opt ica 1  platform,  and  "blind"  landing  evaluations  using 
only  external  sensors  for  such  aircraft  as  the  US  National  Aerospace  Airplane  (NASP). 
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Figure  16.  -  Mimic  Nose  on  ASTTA  (Artist’s  Conception) 

Finally,  a  plan  is  being  evolved  in  conjunction  with  the  USAF  Human  Resources 
Laboratory  (HRL)  to  incorporate  a  fighter  cockpit  with  state  of  the  art  displays  in  the 
cabin  of  the  ASTTA  aircraft.  Surrounding  the  cockpit  will  be  a  simulator  visual  dome 
(Figure  17).  By  having  independent  control  over  the  cockpit's  "motion  base",  its  visual 
field,  and  its  displays,  tests  will  be  conducted  to  determine  requirements  for  ground 
simulators  with  specified  objectives  in  training.  With  the  ability  to  project  on  the 
visual  screen  either  computer  generated  imagery  (CGI)  or  real  world  imagery  (via  the 
ASTTA ‘ a  slewable  camera  systems),  studies  dealing  with  simulator  fidelity,  avionics 
integration,  and  human  factors  Issues  can  be  readily  performed. 


Figure  17.  -  Fighter  Cockpit  and  Visual  [>ome  Onboard  ASTTA  (Artist's  Conception) 

CONCLUSIONS 

This  paper  has  examined  two  important  issues  in  the  development  of  complex  avionics 
systems:  avionics  systems  training  for  both  designers  and  testers,  and  the  avionics 

systems  development  process  itself.  The  tester  training  issue  is  being  tackled  at  both 
the  USAF  and  USN  Test  Pilot  Schools  at  this  time*  training  for  system  design  engineers, 
though  started  to  some  extent,  is  in  its  infancy  and  may  remain  there  without  some 
emphasis  and  push  from  management.  Many  of  today's  avionics  development  problems  are  the 
result  of  attempting  to  fly  without  adequate  operator-in-the-loop  simulation  resulting  in 
a  fly-fix-fly  process  which  proceeds  at  a  slow  and  costly  pace.  In  many  cases,  very 
limited  funding  is  allocated  for  training  and  simulation,  yet  large  sums  are  spent 
developing  expensive,  complex  hardware.  When  simulation  is  used,  often  too  little  time  is 
allotted,  or  the  simulation  is  inadequate  in  representing  the  in-flight  environment  of  the 
system's  intended  operation.  An  air^rne  avionics  training  and  integration  laboratory, 
such  as  ASTTA,  provides  the  opportunity  to  address  both  the  training  and  developmental 
issues . 

ASTTA  is  in  its  infancy  as  an  unique  USAF  tool  to  fil^  a  significant  gap  in  the 
education  and  experience  of  the  avionics  systems  test  community.  It  provides  a  cost 
effective  means  of  quickly  exposing  both  designers  and  testers  to  the  key  issues  of 
avionics  systems  development  and  in-flight  testing,  especially  the  human  factors  issues 
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associated  with  the  operator  to  systems  interface.  Its  benign  flight  environment  is 
conducive  to  both  initial  and  advanced  training  in  flight  test  techniques*  Furthermore, 
ASTTA  offers  exciting  potential  as  a  test  bed  for  a  large  variety  of  research  and 
development  activities.  Proof-of-concept  testing  is  particularly  attractive  with  minimum 
packaging  required  of  test  devices  and  the  ability  to  carry  several  observers  and  even  the 
designers  themselves. 

It  is  the  authors'  hope  that  this  paper  hs  instilled  awareness  of  the  avionics 
systems  training  problems  and  the  need  for  airborne  simulation  in  a  realistic  operational 
environment.  The  future  of  avionics  systems  development  is  being  shaped  now,  and  aircraft 
like  ASTTA  should  be  part  of  that  future  I 


B.Sigaud,  FR 

Please  comment  on  the  problems  of  using  ASTTA  for  avionics  development  relative  to; 

( 1 )  Simulators  versus  actual  hardware. 

(2)  Time  scale  expanded. 

(3)  Nonrepresentation  of  pilot  stres.s  in  actual  environment. 

.\uthor*s  RepI) 

( 1 )  Although  we  currently  use  actual  flight  hardware,  we  could  use  prototype  boxes  or  even  simulate  the  subsystems 
of  on-hoard  Hawk  computers  or.  if  insufficient,  use  ground  computers  to  simulate  subsystem  and  data  link  to  the 
ASTTA.  (ASTTA  provides  a  real-world  signal-to-noise  environment  for  testing.) 

(2)  Target  speeds  can  be  adjusted  to  reduce  time  expansion  and  increase  stress.  In  any  case,  wc  advocate  the  use  of 
ASTTA  for  early  testing.  If  it  does  not  work  in  “slow”  time,  it  will  not  work  in  a  100-pcrccnt  real  scenario, 
especially  with  an  operator  in  the  loop. 

(3)  We  advocate  complementary  use  of  ASTTA-type  tools  and  tactical  aircraft.  Also,  a  very’  small  portion  of  time  is 
spent  at  high  g  levels  and  high  air  speeds.  The  effects  of  the  high  g  level  and  high  ai  speed  could  be  extrapolated 
somewhat  from  the  “benign”  environment  and  then  verified  in  the  actual  aircraft,  however,  the  "early  look"  may 
identify  many  of  the  problems  you  are  trying  to  avoid. 


RJ.  Young,  CA 

( 1 )  The  requirement  for  formal  systems  flight  test  traitung  is  a  valid  one.  and  the  extension  o*  the  principle  to 
designers,  as  well  as  to  the  lest  community,  i.s  interesting  and  innovative.  The  use  of  the  platform  as  a  flying  test 
bed,  specifically  as  a  simulation  facility  to  support  operator-in-the-loop  integiation  testing,  is  less  clear.  The 
capability  of  systems  integration  laboratories  (Sits)  is  increasing  greatly,  and  dynamic  stimulation  is  becoming 
more  feasible. 

(2)  Would  it  not,  therefore,  be  more  effective  and  less  costly  to  involve  the  operator  more  in  the  original  SIL  activity 
rather  than  to  attempt  to  develop  and  duplicate  the  SIL  in  a  lest  bed  and  'or  ass(Kiaicd  ground  support  facility 
simply  as  a  method  to  “involve  the  operator  earlier”? 

Author's  Reply 

( 1 )  Yes,  the  capabilities  of  SfLs  arc  increasing,  but  the  fidelity  to  properly  emulate  the  airborne  environment  does  not 
yet  exist.  Even  today’s  best  ground-based  simulators  are  limited  in  their  ability  to  transfer  learning  and  would  have 
a  similar  effect  in  SfLs  to  properly  represent  the  operator’s  environment. 

(2)  Yes  and  no,  you  must  evaluate  each  development  and  the  risks  involved  to  make  a  value  judgement  on  the  fidelity 
requirements  for  airborne  simulation.  In  many  cases,  it  may  not  require  the  same  effort  or  duplication  of  the  SIL. 
since  the  operator’s  environment  would  not  have  to  be  artificially  duplicated.  Much  of  the  SIL  hardware  software 
could  be  transferred  directly  to  the  airborne  simulator.  Only  the  .systcm/aircrafi  interface  would  differ  if  you  have 
an  airborne  simulator  with  a  flexible  aircraft  bus  structure  and  minimum  packaging  requirements. 


W.E.HowelL  US 

This  comment  is  in  respon.se  to  Major  Young’s  question.  Because  of  the  complexity  of  software  and  the  time  it  takes  to 
develop  it,  it  is  sometimes  cheaper  and  faster  to  put  a  prototype  system  on  an  aircraft  and  fly  it.  Furthermore,  the  results 
are  highly  credible  even  to  those  not  involved  in  the  particular  technical  field  being  evaluated. 


Question; 

Are  the  TTFS  aircraft  and  the  ASTTA  aircraft  one  aircraft  with  interchangeable  nose  and  research  hardware? 


▼ 
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Auttwr's  Reply 

Yes.  and  the  strengths  of  each  capability  can  be  used  jointly,  although  the  nose  change  precludes  using  the  fly-by-wire 
cockpit  and  the  ASTTA  tactical  s^^nsors  at  this  time. 


M.Kayton,  US 

This  is  not  a  question;  it  is  a  comment  on  the  avionics  design  process.  In  your  paper,  you  say  you  want  to  i  ^duce  the 
number  of  system-level  “oand-aids”  by  offering  training  flights  to  avionic  engineers  and  managers.  Training  rides  are  a 
fine  idea,  but  in  30  years’  of  avionic  system  design.  I  have  found  that  the  highest  cost  band-aids  result  from  premature 
release  of  preliminary  designs,  not  from  flight  control  problems.  Premature  release  occurs  when  the  Government 
program  manager  or  company  project  manager  provides  too  little  money  for  preliminary  design  or  forces  the  earlv 
release  to  hardware  and  software  contractors.  Often,  one  more  iteration  of  the  design,  taking  2  to  4  months,  would 
improve  product  quality  enormously.  Instead,  premature  release  leads  to  delays  of  a  year  or  more  and  to  costs  that  arc 
hundreds  of  times  hi^er  than  the  extra  iteration  of  the  preliminary  design.  Unfortunately,  the  ASTTA  cannot  educate 
the  managers  on  the  best  time  to  release  Lhc  preliminary  avionics  design. 
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SUMMARY 

The  software  engineering  approach  adopted  by  British  Aerospace  in  the  specification, 
design  and  implementation  of  th-^  Avionics  and  Utility  Systems  Management  software  for  the 
Experimental  Aircraft  Programme  (EAP)  is  described. 

The  software  life  cycle  and  supporting  rnthods  and  tools  are  described,  in  particular 
the  Controlled  Requirements  Expression  (CORE)  method,  supported  by  the  CORE  Work  Station, 
and  the  PERSPECTIVE  programming  support  environment.  The  considerable  benefits  obtained 
in  both  productivity  and  quality  are  highlighted  and  developments  are  indicated  leading 
to  a  full  Integrated  Project  Support  Environment  (IPSE). 


1 .  INTRODUCTION 

In  May  1983,  British  Aerospace  (BAe)  signed  a  contract  with  the  UK  Ministry  of 
Defence  to  design  and  produce  a  new  aircraft  as  a  technology  demonstrator,  the  programme 
to  be  known  as  the  Experimental  Aircraft  Programme  (EAP).  EAP  achieved  first  flight  in 
August  1986,  was  demonstrated  at  Farnborough  1986  and  is  continuing  a  programme  of  flight 
trials  to  extend  its  flight  envelope  and  explore  the  application  of  its  advanced 
technology. 

The  areas  of  advanced  technology  are  extensive  and  include  an  active  flight  control 
system,  an  all-electronic  cockpit,  and  software  control  of  utility  systems  in  the  systems 
area,  and  extensive  use  of  CFC  and  super-plastic  forming  and  diffusion  bonding  techniques 
in  the  airframe  construction.  The  programme  has  involved  extensive  European  collaboration 
the  advanced  technologies  having  evolved  from  various  government  research  contracts  over 
the  past  decade.  The  technologies  will  be  utilised  in  any  future  fighter  aircraft 
programme  with  UK  involvement  the  European  Fighter  Aircraft  (EFA)  project  being  a  current 
project , 

A  less  visible  aspect  of  EAP  is  the  successful  application  of  a  software  engineering 
approach  that  had  been  developed  by  BAe  via  a  number  of  small  research  projects  since  the 
late  1970's  and  for  which  the  EAP  project  provided  the  first  large  scale  use.  The 
software  engineering  approach  is  the  subject  of  this  paper. 


2.  BAP  SYSTEMS  ARCHITECTURE 

The  EAP  systems  architecture  is  illustrated  in  Fig.  1.  It  consists  of  3  major 
sub-systems : 

Flight  Control  System  (FCS) 

.  Avionic  System  (AVS) 

.  Utilities  Systems  Management  System  (USMS) 

The  AVS  and  USMS  each  incerporate  a  Mil  Std  1553  databus  architecture  and  the  3 
sub-systems  communi  ate  via  Remote  Terminals  on  the  AVS  databus. 

The  FCS  is  a  full  authority  digital  quadruplex  fly-by-wire  system.  For  such  a 
flight  safety  critical  system  a  significantly  different  approach  is  required  for  the 
design  and  develop’^ent  ■  f  the  software.  In  particular  the  use  of  a  low  level  language 
and  a  reduced  instruction  set  is  the  norm.  The  EAP  PCS  is  a  derivative  of  the  existing 
Jaguar  fly-by-wire  demonstrator  aircraft  system  for  which  a  specialised  technique  had 
already  been  developed  to  support  the  software  production  (I).  This  technique  was  used 
again  for  EAP  FCS  and  is  not  discussed  further  here. 

The  main  feature  of  the  AVS  is  the  all-electronic  cockpit  with  multi-function  colour 
displays  generated  and  moded  under  software  control  according  to  phase  of  flight  and 
pilot  selection.  The  AVS  also  includes  navigation  and  communication  functions  and 
extensive  failure  detection  and  warning  handling  under  software  control. 


The  USMS  provides  software  control  of  many  of  the  aircraft  mechanical  systems  that 
have  traditionally  been  controlled  by  analogue  means,  in  particular  the  following  are 
controlled  via  the  USMS:  undercarriage  selection,  braking,  cabin  te-.iperature  control  and 
environmental  control  system,  hydraulics,  engines,  secondary  power  system,  fuel 
management,  fuel  gauging  and  level  sensing,  and  miscellaneous  minor  systems. 

The  software  engineering  approach  described  in  this  paper  was  applied  to  a  limited 
set  of  the  processors  for  which  BAe  had  software  design  lead  within  the  AVS  and  USMS. 
Nevertheless  this  limited  set  provided  a  range  of  2  distinct  CPU  types  and  9  processor 
architectures.  Within  each  of  the  processors  software  developed  by  other  suppliers  was 
co-resident  with  the  BAe  software- 

The  total  software  content  of  the  processors  considered  amounts  to  some  400K  words 
of  which  over  300K  words  were  supplied  by  BAe.  However,  there  exists  an  amount  of 
duplication  within  the  AVS  and  USMS  so  that  the  total  amount  of  unique  software  developed 
amounts  to  225K  words.  For  each  of  the  processors  BAe  was  also  responsible  for 
integration  and  acceptance  proving  of  the  total  software  load. 


3.  BAP  SOFTWARE  MANAGEMENT 

In  order  to  control  the  software  development  for  a  multi-processor,  multi-team 
project,  a  central  software  management  team  was  created  by  BAe  independent  of  the  BAe 
software  development  team.  Thus  the  BAe  software  development  team  was  considered  in  the 
supplier  context  and  the  management  team  enforced  standards  and  control  procedures  across 
all  supplier  teams.  In  particular  the  essential  configuration  management  and  quality 
control  roles  were  performed  by  the  software  managei^ent  team. 

Existing  BAe  standards  covering  the  software  life-cycler  already  compatible  with 
required  defence  standards  were  supplemented  with  specific  standards  to  take  account  of 
the  particular  methods  and  tools  to  be  used.  Also  model  texts  were  produced  to  specify 
the  documentation  requirements  for  each  phase  of  the  life-cycle.  The  use  of  project 
specific  standards  and  model  texts  ensured  a  uniform  application  of  the  methods  and  tools 
across  the  various  teams. 

In  conjunction  with  the  project  standards,  the  management  team  also  established 
management  control  procedures  to  define  the  procedures  for  review,  configuration,  release 
for  issue  and  change  control  mechanisms  for  documents  and  software  components. 
Considerable  emphasis  was  placed  on  achieving  quality  in  the  final  product  both  through 
the  "built  in"  quality  inherent  through  the  particular  methods  and  tools  used  and  through 
the  life-cycle  review  procedures.  In  addition  to  the  quality  control  function  exercised 
by  the  management  team  to  ensure  adherence  to  the  standards,  a  member  of  the  independent 
Quality  Assurance  department  was  seconded  to  the  project.  The  quality  assurance 
representative  reported  directly  to  the  project  manager  on  adherence  to  standards  and 
procedures  and  carried  out  an  independent  check  on  the  configuration  standard  of  life- 
cycle  documents  and  changes  and  confirmed  that  sufficient  and  necessary  testing  had  been 
completed  before  software  release. 

Additionally,  during  the  software  design  and  code  phases  an  independent  technical 
audit  team  was  employed  to  review  adherence  of  design  to  requirements  and  of  code  to 
design,  including  the  effect  of  changes. 


<.  EAP  SOFTWARE  LIFE-CYCLE  i  METHODOLOGY 

The  software  life-cycle  is  illustrated  in  Fig.  2.  Although  the  derivation  of  system 
functional  requirements  may  be  considered  to  precede  the  software  life-cycle,  the  phase 
is  included  here  because  it  was  supported  by  the  methodology.  In  essence  the  approach 
consists  in  supporting  each  phase  of  the  life-cycle  by  a  suitable  method  with  each  method 
or  technique  in  turn  supported  by  a  suitable  tool.  Whilst  this  philosophy  is  not  new, 
the  scale  of  application  and  the  degree  of  integration  achieved  with  the  methods  and  tools 
on  EAP  were  innovative  and  contributed  significantly  to  the  success  of  the  software 
development . 

The  particular  methods  and  tools  employed  are  annotated  on  Fig.  2  and  will  be 
discussed  in  terms  of  their  li^e-cycle  application  in  the  next  section.  Two  items  are 
singled  out  here  for  further  discussion  as  they  formed  the  foundation  of  the  software 
engineering  approach,  CORE  and  PERSPECTIVE. 

4 . 1  CORE 

CORE,  controlled  Requirements  Expression,  arose  out  of  research  ai  BAe  aimed  at 
improving  the  requirements  phases  of  the  life-cycle.  The  research  had  concentrated 
on  the  requirements  phase  since  it  was  well  known  that  the  later  that  errors  are 
discovered  during  the  life-cycle  the  more  costly  they  are  to  fix.  Also  traditionally 
requirement  errors  were  not  discovered  until  late  in  the  life-cycle  and  were 
considerable  in  nu^ober.  Thus  any  approach  that  could  improve  the  integrity  of  the 
requirement  phases  would  give  a  considerable  leverage  on  cost  reduction.  The  outcome 
of  the  research  was  the  development,  in  conjunction  with  Systems  Designers  pic,  of 
the  CORE  method. 


The  CORE  method  is  a  top-down  approach  fo*-  analysing  and  expressing 
requirements  in  a  contrwiled  and  precise  manner.  It  enables  a  subject  requirement 
to  be  expressed  in  terms  of  lower  level  requirements  which  may  in  turn  be  subjected 
to  the  method  +0  produce  a  hierarchy  of  lower  levels.  The  method  comprises  a  number 
of  logical  steps  which  can  be  summarised  as  information  gathering,  proposal  of 
relationships  and  confirmation  of  relationships.  The  steps  are  described  and  the 
method  compared  with  other  techniques  in  12]. 

A  diagrammatic  notation  is  used  extensively  in  CORE  as  an  aid  to  understanding 
and  to  provide  an  unambiguous  expression  of  the  structure  of  the  subject  requirement, 
the  data  flows*  data  dependencies*  processing  actions  and  the  time  ordering  of  those 
actions.  The  notation  is  illustrated  in  Pig.  3.  Production  of  CORE  diagrams  has 
been  automated  in  the  CORE  Work  Station  developed  by  British  Aerospace.  The  CORE 
Work  Station  provides  a  multi-user  development  environment  for  the  production  of 
CORE  requirements.  It  consists  principally  of  a  diagram  editor  which  allows 
diagrams  to  be  entered  and  manipulated  via  a  high  resolution  graphics  terminal,  a 
multi-user  database  for  the  storage  and  retrieval  of  diagrams  and  a  hard  copy 
facility.  Some  automatic  on-line  checking  of  diagrcuns  is  available  during  editing, 
and  off-line  checks  are  available  for  more  comprehensive  checking. 

4 . 2  PERSPECTIVE 

PERSPECTIVE  is  a  proprietary  product  of  Systems  Designers  pic,  which  provides 
a  multi-user  programming  support  environment  for  the  development  of  embedded 
computer  systems  written  in  Pascal.  The  product  arose  wUt  of  considerable  experience 
in  the  development  of  cross-compilers  and  support  environments  for  embedded  systems 
and  first  appeared  on  the  market  place  in  1983, 

Whilst  the  maturity  of  the  product  was  rightly  questioned  for  application  in 
the  EAP  timescales,  for  the  chosen  language  Pascal,  the  features  offered  by  the 
product  were  considered  to  far  outweigh  any  risk  associated  with  immaturity. 

PERSPECTIVE  supports  a  particular  modular  design  technique  which  has  been 
implemented  through  extensions  to  the  ISO  standard  Pascal.  The  technique  is  oased 
on  a  data  flow  model  of  a  real  time  system,  and  decomposes  the  structure  of  the 
software  into  three  basic  component  types,  processes,  interfaces  and  modules.  The 
processes  are  the  fundamental  units  of  parallel  processing  within  PERSPECTIVE  and 
consist  of  independently  schedulable  units  of  sequential  code.  Processes  can  only 
communicate  with  each  other  via  the  facilities  specified  in  the  interfaces.  The 
interfaces  contain  only  the  specification  of  the  facilities  available,  the 
implementation  of  these  facilities  is  defined  in  the  modules.  Modules  may  also  use 
the  facilities  defined  in  other  interfaces,  so  that  the  concept  of  software  layering 
or  successive  layers  of  abstraction  is  inherent  in  the  technique.  The  basic 
components  may  be  grouped  into  larger  components  termed  subsystems  which  again  can 
only  communicate  via  interfaces.  The  technique  is  supported  by  a  diagrammatic 
notation  which  is  summarised  in  Fig.  4.  The  notation  has  been  automated  in  the  CORE 
Work  Station  to  provide  computer  support  of  the  design  technique. 

PERSPECTIVE  Pascal  also  includes  extensions  to  provide  basic  primitives  for 
the  manipulation  of  processes  to  enable  the  implementation  of  the  required  scheduling 
regime  for  a  particular  application.  The  basic  primitives  are  implemented  in  a  run 
time  system  supplied  in  source  code  which  may  be  tailored  for  any  particular  hardware 
configuration. 

The  design  concepts  and  notation  of  PERSPECTIVE  are  very  akin  to  the  MASCOT 
approach  [31.  Earlier  research  work  at  British  Aerospace  had  indicated  that  a 
requirement  expressed  in  CCRE  notation  could  be  mapped  into  a  MASCOT  design  diagram, 
so  that  for  EAP  it  proved  a  straightforward  extension  to  map  the  CORE  requirements 
into  PERSPECTIVE  designs. 

Central  to  the  PERSPECTIVE  support  environment  is  a  multi-user  database  in 
which  are  stored  the  source  code  files  and  all  associated  derived  products  for  the 
components  of  one  or  more  systems.  The  database  is  configured  as  a  number  of 
independent  user  domains  permitting  independent  development  of  components. 

Components  may  be  shared  between  domains  through  the  use  of  a  publish  and  acquire 
facility.  Components  may  exist  in  multiple  versions  and  extensive  management 
facilities  are  provided  to  keep  track  of  versions,  relationships,  status,  access 
rights  etc,  providing  the  essentials  for  configuration  control. 

Software  development  within  PERSPECTIVE  is  carried  out  in  two  major  phases. 

Host  and  Target.  During  the  host  phase  components  are  compiled  and  debugged  through 
execution  on  the  host  (VAX  series)  computer.  Checkout  facilities  are  built-in  to 
enable  source-code  level  debugging,  including  single-stepping,  breakpoint  setting, 
data  alteration  and  data  and  system  monitoring.  For  the  target  phase  the  components 
are  re-compiled  for  the  target  configuration  and  downloaded  via  a  terminal  line  to 
the  target  processor.  Execution  in  the  target  may  continue  independently  from  the 
host  or  the  host  link  may  be  retained  to  allow  checkout  of  the  target  software  via 
the  host  facilities  in  a  similar  manner  to  host  checkout.  Complete  target  memory 
images  may  also  be  generated  via  a  'PROM'  facility  within  PERSPECTIVE  which  generates 
files  suitable  for  subsequent  processing  by  IC  programming  devices. 


32-4 


5.  BAP  SOP1WARB  TOOLSET  LIFB-CYCLB  APPLICATXOli 

This  section  discusses  the  methods  and  tools  further  in  the  context  of  their 
application  to  the  EAP  software  life-cycle. 

5.1  Bequirettenta  Oefiaition 

Requirements  definition  encompassed  the  two  phases  of  System  Functional 
Requirements  and  Software  Requirements.  Both  phases  were  carried  out  by  system 
engineering  staff  (as  distinct  from  software  engineers)  utilising  the  CORE  method, 
implemented  in  the  CORE  work  station. 

Two  different  approaches  were  adopted  for  the  AVS  and  USMS  arising  from  the 
essentially  different  nature  of  the  systems.  The  AVS  consists  of  a  highly 
integrated  system  where  the  problem  consisted  in  identifying  and  elaborating  the 
various  functions  and  then  allocating  them  to  defined  processing  units.  The  USMS 
consists  of  a  number  of  largely  independent  subsystems  which  required  independent 
analysis  and  then  integration  into  a  defined  processing  architecture.  The  routes 
taken  in  each  case  are  shown  in  Pig.  5.  In  e&ch  case  the  end  result  was  a  set 
processor  software  specifications. 

Each  processor  software  specification  consists  of  a  set  of  CORE  documentation 
supplemented  by  information  on  hardware/software  interfaces,  constraints,  error 
detection  and  handling,  scheduling  etc.  The  CORE  documentation  consists  of  a  set 
of  thread  diagrams,  which  show  the  required  independent  threads  of  execution  within 
the  processor,  an  operational  diagram,  which  shows  the  required  time-ordered 
relationship  between  the  individual  threads,  and  data  decomposition  diagrams  for 
complex  data  items.  The  diagrams  are  supplemented  by  "node  notes”  which  supply 
brief  textual  descriptions  of  each  process  in  a  thread  diagram  and  each  data  line 
entering  or  leaving  the  diagram.  The  node  notes  form  part  of  the  CORE  documentation 
set  and  are  entered  into  the  CORE  database  via  the  work  station.  A  typical  thread 
diagram  is  presented  in  Pig.  6. 

In  addition  to  the  processor  software  specification,  the  system  engineering 
staff  produced  an  acceptance  test  specification  for  each  processor  which  served  as 
the  acceptance  requirement  for  delivery  of  processor  software  for  subsequent  system 
integration. 

5.2  Basic  Design 

The  basic  design  phase  consisted  of  the  translation  of  each  processor  software 
specification  into  a  definition  of  the  modular  structure  of  the  software  within  the 
processor  and  an  identification  of  all  software  components.  The  basic  design  was 
carried  out  by  the  BAe  software  team  with  participation  from  suppliers  of  co-resident 
software  where  applicable.  The  PERSPECTIVE  design  approach  was  followed,  supported 
by  the  CORE  work  station.  In  essence  the  design  consisted  of  a  grouping  of  the  CORE 
threads  defined  in  the  software  specification  into  suitable  PERSPECTIVE  processes 
and/or  subsystems  and  a  grouping  of  the  data  items  into  suitable  interfaces  with 
specified  access  procedures.  A  typical  basic  design  diagram  is  presented  in  Fig.  7. 

Also  during  the  basic  design  phase  the  required  testing  plan  for  the  processor 
was  specified.  This  identified  the  order  of  testing  of  components  and  the  necessary 
test  components  to  progressively  test  and  integrate  the  software  within  the  processor 
leading  to  acceptance  test  of  the  full  processor  load. 

5.3  Detailed  Design 

Tne  detailed  design  phase  consisted  of  elaboration  of  the  detail  for  each 
software  component  and  test  component  defined  during  the  basic  design  phase.  For 
this  phase  the  work  was  carried  out  independently  by  the  various  software  teams, 
working  to  the  precise  specifications  derived  during  the  basic  design  phase. 

Since  much  of  the  detail  was  contained  in  the  detailed  layering  of  the 
processor  software  specification  CORE  threads,  it  was  possible  to  transfer  this 
information  into  the  detailed  design  supplemented  by  definition  of  data  types  and 
structures  and  access  procedures.  Again  the  CORE  work  station  was  used  to  transfer 
the  thread  information  into  detailed  design  diagrams  and  to  add  the  extra  information. 
Where  necessary  the  diagrauns  were  supplemented  by  pseudo-code  node  notes.  A  typical 
detailed  design  diagram  is  presented  in  Fig.  8. 

5.4  Coder  Test,  Integration 

The  code,  test  and  integration  phases  were  performed  using  the  PERSPECTIVE 
support  environment.  The  PERSPECTIVE  database  facilities  were  used  to  store  the 
code  of  all  design  components  and  test  components  and  the  various  build  standards 
leading  to  complete  processor  software  builds.  Generally  the  test  and  integration 
phases  were  as  follows: 

.  Host  test  of  individual  Pascal  components  using  test  components  where  necessary 
and  previously  tested  components  when  available.  For  the  host  tests  extensive 
use  was  made  of  the  PERSPECTIVE  checkout  facilities. 


.  Repeat  of  the  host  test  on  the  target  processor  using  the  PERSPECTIVE  download 
and  checkout  facilities. 

.  Target  test  of  assembler  language  components  using  the  download  and  checkout 
facilities . 

.  Progressive  integration  and  test  of  components  in  the  target  processor  using  the 
download  and  checkout  facilities. 

In  practice  the  repeat  of  the  host  testing  on  the  target  processor  was  found 
to  be  unnecessary  as  no  errors  were  introduced  by  recompilation  for  the  target,  and 
this  phase  was  subsequently  omitted. 

Assembler  language  components  were  necessary  in  some  instances  to  interface 
with  processor  hardware  or  for  critical  timing  areas.  Within  PERSPECTIVE  assembler 
language  is  confined  to  module  components. 

Two  additional  tools  were  employed  during  the  target  testing  and  integration 
phases.  A  comprehensive  Data  Acquisition  and  Simulation  System  (DASS)  attached  to 
the  overall  aircraft  test  rig  was  used  to  stimulate  and  monitor  hardware  interfaces. 
Also  microprocessor  development  systems  (MDS)  were  used  for  processor  emulation, 
rtate  analysis  and  logic  analysis  operations.  The  MDS  facilities  proved  especially 
useful  in  resolving  hardware/software  conflicts. 

Whilst  software  developers  could  initially  carry  out  informal  testing  on 
uncontrolled  items  for  experimencal  or  confidence  checking,  eventually  the  required 
testing  was  carried  out  formally  on  "frozen"  components  under  control  of  a  central 
software  librarian.  This  was  achieved  through  the  PERSPECTIVE  configuration  control 
facilities.  Each  developer  was  assigned  a  unique  user  domain  and  special  protected 
domains  were  assigned  to  the  software  library.  Components  ready  for  configuration 
control  were  submitted  via  a  registration  procedure  to  the  librarian  and  transferred 
to  a  library  domain.  Components  in  the  library  domain  were  published  and  could  be 
acquired  by  developers  for  incorporation  into  test  builds  as  necessary,  however  the 
components  were  effectively  frozen  and  unable  to  be  modified  by  acquirers.  A  version 
numbering  convention  was  enforced  by  the  librarian  to  accommodate  formal  changes  of 
components  and  coding  standards  included  a  header  comment  identifying  the  version 
change  history  of  the  component.  Through  these  simple  but  effective  facilities, 
components  were  progressively  transferred  from  development  domains  to  library 
domains,  building  a  complete  library  of  components  under  configuration  control  with 
full  design  traceability. 

An  important  feature  implemented  as  part  of  the  library  procedure  was  an 
independent  technical  audit  of  source  code  components  on  registration  with  the 
library.  This  ensured  conformity  to  design  documents  and  formal  changes,  and 
conformity  to  the  project  coding  standards. 

As  part  of  the  integration  task,  BAe  was  required  to  incorporate  the  software 
delivered  from  other  suppliers.  The  modular  structure  of  the  software  enforced 
through  the  PERSPECTIVE  facilities  resulted  in  a  virtually  trouble  free  integration 
of  PERSPECTIVE  components.  More  significant  problems  occurred  in  certain  cases 
where  suppliers  had  not  used  the  PERSPECTIVE  approach,  however  overall  the  problem 
of  integrating  separately  sourced  software  were  considered  to  be  minimal. 

Formal  releases  of  software  for  system  rig  testing  or  aircraft  use  were 
assembled  by  the  librarian  in  PERSPECTIVE  databases  from  the  component  library. 

Following  acceptance  of  the  releases,  the  subsequent  system  rig  testing  and 
system  integration  were  carried  out  by  the  Systems  Test  department,  a  separate 
organisation  independent  from  the  software  teeuns,  making  use  of  the  DASS  facility. 

For  early  processor  units  with  RAM  storage,  the  systems  test  team  made  use  of  the 
download  facility  to  load  the  units  directly  from  the  PERSPECTIVE  databases.  For 
later  units  with  ROM  storage,  memory  images  were  generated  by  the  software  library 
via  PERSPECTIVE  facilities  and  subsequently  programmed  into  storage  devices. 

Errors  discovered  during  system  testing  were  corrected  via  changes  raised  on 
the  appropriate  requirement  and/or  design  document  and  affected  code  components 
were  raised  in  issue  and  re-tested.  The  implications  of  changes  were  easy  to  assess 
and  few  side  effects  were  encountered.  As  confidence  was  gained  in  the  approach, 
only  incremental  re-test  was  undertaken  by  the  software  team  on  re-reiease. 


6.  BENEFITS  OF  APPROACH 

The  benefits  of  the  software  engineering  approach  described  have  been  assessed  by 
comparing  the  results  achieved  on  EAP  with  the  experience  at  British  Aerospace  on  earlier 
projects.  The  main  gains  are  an  increase  in  both  productivity  and  quality.  Compared 
with  the  two  most  recent  projects,  the  productivity  measured  in  delivered  lines  of  code 
per  man  year  for  the  software  design  code  and  test  phases  has  increased  five-fold.  The 
quality  measured  in  terms  of  errors  detected  during  rig  flight  clearance  testing  expressed 
as  a  ratio  per  line  of  delivered  code  has  improved  by  almost  a  factor  of  ten.  This 
increase  in  quality  and  productivity  has  resulted  in  a  considerable  estimated  saving  in 
the  total  resources  needed  for  design  and  rig  testing,  which  outweighs  the  expense  of 
introducing  the  methods  and  tools  by  a  factor  of  six. 
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The  use  of  well-defined  methods  and  tools  also  provided  a  detailed  framework  tor 
training,  enabling  a  comprehensive  training  scheme  to  be  planned  which  allowed  relatively 
inexperienced  staff  to  be  brought  up  to  speed  reasonably  quickly.  The  modular  approach 
supported  by  the  methods  and  tools  also  allowed  the  introduction  of  large  numbers  of 
extra  staff  during  the  detail  design,  code  and  test  phases  to  keep  the  project  on  time 
schedule.  In  fact  the  peak  software  design  team  manning  at  British  Aerospace  reached 
60  whereas  the  maintenance  of  the  software  to  incorporate  requirements  changes  resulting 
from  flight  experience  is  handled  by  a  team  of  4. 


7.  CONCLUDING  REMARKS 

The  software  engineering  approach  described  has  undoubtedly  contributed  to  the 
success  of  the  EAP  project  in  meeting  an  extremely  tight  timescale.  Also  results 
indicate  that  the  quality  of  the  delivered  software  and  the  productivity  achieved  have 
both  improved  considerably  through  the  approach.  The  firmly  held  view  within  British 
Aerospace  is  that  the  use  of  the  CORE  method  supported  by  the  CORE  workstation  has  been 
a  major  factor  in  the  success  through  ensuring  a  structured  top-down  approach  resulting 
in  quality,  consistent  requirements  and  providing  an  essential  continuity  through 
the  software  life-cycle  into  the  design  phases.  PERSPECTIVE  represencs  the  state-of-the- 
art  in  support  environments  for  embedded  applications  using  the  Pascal  language  and  was 
a  further  major  factor  in  the  success.  Both  CORE  and  PERSPECTIVE  are  in  current  use  on 
further  projects  within  British  Aerospace. 

Developments  of  the  approach  for  future  projects  are  aimed  at  the  introduction  of 
the  language  and  providing  a  truly  integrated  project  support  environment  (IPPE). 

Whilst  the  methods  and  tools  of  the  current  approach  are  integrated  in  the  sense  that 
they  are  compatible  and  consistent  from  phase  to  phase  of  the  life-cycle,  nevertheless 
the  products  of  the  requirements,  design  and  code  phases  are  held  in  distinct  databases, 
each  subject  to  individual  configuration  management  procedures  and  considerable  manual 
intervention  is  required  to  ensure  overall  configuration  control.  The  IPSE  approach  alms 
to  utilise  a  common  database  implementation  tool  so  that  all  life-cycle  products  are 
subject  to  a  common  version  and  variant  control  mechanism,  thus  enabling  automated 
configuration  management  across  the  total  life-cycle. 

Several  products  are  appearing  on  the  market  place  which  provide  a  basic  IPSE 
framework  giving  the  essential  database  manipulation  and  management  facilities,  and 
which  permit  the  integration  of  specific  tools  via  a  tool  interface. 

Currently  British  Aerospace  in  col laboratioi.  with  partner  companies  is  involved  in 
the  procurement  of  a  basic  IPSE  framework  and  the  development  and  incorporation  of 
specific  tools.  Two  particular  areas  of  development  are  worthy  of  note.  Firstly  CORE 
has  been  integrated  with  EPOS  f4|  which  allows  the  EPOS  facilities  to  be  used  for 
extensive  analysis  of  CORE  data  and  makes  available  the  extensive  EPOS  documentation 
facilities.  Secondly  guidelines  are  being  developed  for  the  translation  of  requirements 
expressed  in  CORE  diagrammatic  notation  into  software  design  structures  suitable  for  Ada 
implementation. 

An  IPSE  schematic  is  shown  in  Pig.  9,  however  the  specific  tools  indicated  are 
illustrative  only.  The  IPSE  development  which  will  form  the  basis  of  the  software 
engineering  approach  for  future  projects  and  in  particular  the  European  Fighter  Aircraft 
(EFA)  will  serve  to  maintain  the  improvement  trends  in  quality  and  productivity  already 
observed  for  EAP. 


8 .  REFERENCES 

(IJ  Daley  E.,  Smith  R,  B.  :  'Flight  Clearance  of  the  Jaguar  Fly-by-Wire’. 

Certification  of  Avionic  Systems,  The  Royal  Aeronautical  Society,  London. 
April  1982. 

[2]  Price  C.  Forsyth  6.  Y.  :  'Practical  Considerations  in  the  Introduction  of 

Requirements  Analysis  Techniques*.  Proceeding  No.  330,  AGARD  Software  for 
Avionics.  Sept.  1982. 

[3]  'The  Official  Handbook  of  MASCOT’  MASCOT  2  Issue  2.  Royal  Signals  and  Radar 
Establishment,  Malvern.  March  1983. 

f4l  Biewald  J.,  Goehner  P.,  Lauber  R.,  Schelling  H.  :  'EPOS  -  A  Specification  and 
Design  Technique  for  Computer  Controlled  Real-Time  Automation  Systems'. 

Proc.  4th  Int.  Conf.  Software  Engineering,  Munich  1979.  IEEE  Comp.  Soc., 

Los  Alamitos,  Cal.,  1979,  pp  245-250. 


9.  ACKIKWLBDGBKBNT 

This  work  has  been  carried  out  with  the  support  of  the  Procurement  Executive, 
Ministry  of  Defence. 

(R)  Ada  is  a  registered  trademark  of  the  U.S.  Government  -  Ada  Joint  Program  Office. 


32-9 


INTERFACES 


o 


PROCESS 


MODULES  IMPLEMENTING 
INTERFACES 


SUB-SYSTEM 


SUB-SYSTEMS  IMPLEMENTING 
INTERFACES 


RG.4  PERSPECTIVE  NOTATION 


FUMCTKMAL  FUMCTK>NAL  i 

REOOWEttEHT  REOUmEMENT  ' 

VIEWPOINTS  VIEWPOIMTS 


PRE-OEFINED  COCKPTT 

FUNCTIONS  FUNCTIONS  I 


EXEC 

MONITOR  AND 
CONTROL 


SOFTWARE 

REQUIREMENT 


COCKPIT 

INTERFACE 

UMT 


PROCESSOR 

SOFTWARE 

SPECIFICATIONS 


SPECIFICATION 


<  5  » 


FIG.5  SOFTWARE  REQUIREMENT  ROUTES 


US  CJP£  Ol*C»«««  H<H  6i  canwvm.C^^tQ 


©<‘=186  BRITISH  AFP05PACE 
PUBLIC  LiniTED  COMPANY 


1 


32-13 
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DISCUSSION 


M.Muenier,  FR 

You  indicated  that  for  the  EAP,  both  CORE  and  MASCOT  are  used  at  the  design  stage  together  with  real-time  Pascal 
as  an  implementation  language.  On  the  other  hand,  you  plan  to  use  EPOS  for  design  in  the  framework  of  the  EAF 
program  with  Ada  for  coding.  Would  you  comment  on  the  independence  of  design  tools  with  regard  to  programming 
languages? 

Author’s  Reply 

For  EAP,  we  choose  CORE/MASCOT/PERSPECTIVE;  PERSPECTIVE  provided  the  support  enviionment  for 
Pascal. 

For  EFA,  the  required  language  is  Ada,  and  work  is  under  way  to  produce  the  Integrated  Project  Suppo^  Environment 
(IPSE)  that  will  embrace  Ada.  The  system  dcsi^  tool  will  be  CORE/EPOS,  where  the  design  advantage  of  CORE  will 
he  coupled  with  the  cross-checking  advantages  inherent  in  EPOS. 

I  believe  the  design  tCKils  should  be  capable  of  supporting  several  programming  languages;  however,  with  an  aircraft 
program  like  EFA,  an  Ada-dedicated  IPSE  would  be  considered  acceptable. 


P.R.Walwyn.  UK 

(1)  How  ■*m<xlular”  was  the  software  you  produced?  What  son  of  “tasks"  did  you  include  in  discrete  modules  ’ 

(2)  What  proportion  of  your  total  code  consisted  of  “repeat-calls"  of  common  modules? 

{^)  How  "reusable"  do  you  think  your  produced  modules  will  be  for  future  programs  (e.g,  EFAl? 

Author’s  Reply 

( 1 )  The  software  is  highly  modular,  in  which  the  module  size  varies  considerably,  covering  items  such  as  mimilors  or 
track  compute  or  display  drive  logic. 

(2)  Out  of  a  300K  word  software  package.  225K  words  were  unique. 

(.3)  The  software  documentation  requirement  can  be  used  again,  since  it  is  independent  of  project.  However.  I- FA  will 
be  Ada-based,  and  the  software  modules  produced  for  E‘ AP  in  Pascal  will  not  he  reusable. 
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SYSTEME  AVIONIQL  E  -  METHODE  DE  DEVELOPPFMENT  ET  OLTILS 
INFORMATIQUES 

par 

P.Larochc-Levy 
Avu>ns  Marcel  Dassault 
7K.  Quai  Marcel  Dassault 
^2260  Saint  Cloud 
France 


1  -  INTRODUCTION 


Les  plus  rScents  syst^mes  avioniques.  par  le  grand  nOTibrt  de  fonctionnal i tes  qu'lls  offrent 
et  par  1 'utilisation  importarte  de  nouvelles  technologies  dans  leur  realisation  ont  atteint  un  haut 
niveau  de  complexite. 

Pour  en  conserver  la  maitrise,  1 'utilisation  d'outil’.  informatiques  assurant  la  mise  en  oeuvre 
d'une  methodologie  rigoureuse  est  nfcessaire. 

D' importants  travaux  ont  ete  entrepris  aux  AVIONS  MARCEL  DASSAULT  -  BREGUET  AVIATION,  en 
collaboration  avec  d'autres  industriels  ei  la  participation  du  Ministere  de  la  Defense,  pour 
definir  et  developper  un  enjemble  d'outillages  informatiques  homogenes  soutenant  les  diff^rentes 
phases  de  d^veloppement  de  syst^mes  avioniques. 

L'objet  du  present  docuement  est  de  dAc^ire  la  nature  des  besoins  au  regard  du  cycle  de  vie 
du  dAveloppement  des  systAmes  avioniques,  puis  les  principaux  travaux  engages  pour  assurer  la 
couverture  des  differentes  phases. 


2  -  SYSTEME  AVIQNIQUE 

2.1  -  06.IET  D'UN  SYSTEMS  AVIQNIQUE 

Les  principales  fonctions  assurAes  par  un  syst^e  avtonique  concernent  : 

-  le  dialogue  avec  I'Aquipage, 

-  les  fonctions  opArationnel les  (navigation,  conduite  de  tir  d'armes,  reconnaissance,  ...), 

-  la  prAparation  et  la  restitution  de  mission. 

-  la  coopAration  entre  avions  et  le  sol, 

-  la  maintenance  opArationnel le. 

2.2  -  CARACTERISTIQUES  D'UN  SYSTEME  AVIQNIQUE 

Les  systAmes  avioniques  actuels  sent  principalement  . 

-  des  systAmes  trAs  intAgrAs  pour  rApondre  aux  exigences  suivantes  : 

.  assurer  un  grand  nomtre  de  fonctions  opfera*’ionnelles  concourant  ensemble  3  la  reussite 
de  la  mission, 

.  tenir  dan>  un  volume  restreint  et  pour  la  masse  la  plus  rAduite  possible. 


.  garantir  un  bon  niveau  de  dialogue  avec  le  pilote  tout  en  cherchani  a  diminuer  sa 
charge  de  travai 1 , 

Cette  integration  se  traduit  essentiellement  par  une  interdependance  des  fonctions  et 
un  multlplexage  des  ressources  capteurs,  commandes  et  visualisations. 

-  des  systemes  forteinent  evolutifs  pour  : 

.  pouvoir  subir  des  transformations  li^es  S  de  nouvelles  technologies  de  materiel, 

.  etre  capables  de  supporter  1 ' integration  de  fonctions  pour  repondre  a  de  nouveaux 
besoins  operationnels, 

.  perrnettre  des  ameliorations  de  la  mission, 

.  satisfaire  a  des  demandes  specifiques  d‘un  client  par  le  developpement  d'une 
version  particul iere. 

-  des  systemes  hautement  securises  pour  : 

.  assurer  la  securite  de  I'equipage  par  une  gestion  de  pannes  integr6e  (surveillance, 
detection,  reconfiguration), 

Les  progres  technologiques  de  ces  dernieres  annees  ont  permis  une  forte  numerisation  des 
systemes  avioniques  ;  cette  numerisation  s'est  concretisee  par  la  multiplication  de 
processeurs  specialises  dans  les  equipements,  I'utilisation  de  bus  num6riques  et  un  volume 
croissant  des  logiciels- 

Tous  ces  elements  reunis  ont  favorise  la  realisation  de  systemes  de  plus  en  plus  integres, 
performants  et  evolutifs,  mais  dont  le  niveau  de  complexite,  lie  au  grand  volume  de 
logiciels  et  3  la  combinatofre  des  logiques  systemes,  a  rendu  la  maUrise  difficile. 


-  PRQBLEHES  POSES 


Les  probiemes  poses  lors  du  developpement  des  recents  systemes  avioniques  concernent 
particul ierement  : 

-  la  maitrise  des  couts  et  des  deiais, 

-  U  communiration  entre  le  grand  nombre  de  partenaires  industriels  impliques  dans 
un  programme, 

-  la  validation  des  systemes  et  de  leurs  evolutions, 

•  la  gestion  d'une  importante  documentation  de  specifications  et  les  difficultes  dc 
sa  mise  e  jour. 

Les  chiffres  cites  ci-dessous  sont  issus  du  developpement  d'un  systeme  avionique  type 
MIRAGE  2000  et  illustrent  ces  derniers  points. 

Pour  assurer  1 ‘ensemble  des  fonctions  de  "base"  dites  de  conduite  de  la  machine 
(conditionnement,  generation  eiectrique.  pilotage,  navigation,  localisation,  ...)  et  des 
fonctions  specifiques  missions  {contre-mesures,  interception  air/air,  ottaqucs  air/sol, 
reconnaissance,  ...)  le  systeme  avionique  conduit  i  1 ’ integration  d'une  centaine  d'equipements 
et  a  la  realisation  de  500  Kmots  de  logiciels  embarques. 

Rapportes  aux  differentes  phases  du  cycle  de  vie,  les  volumes  de  documentations  associees 
sont  ; 


-  definition  et  specification  systeme 

.  1 'ensemble  de  la  documentation  de  specification  systeme  represente  une  hauteur  de 
1 'ordre  de  3  metres. 

-  conception  et  realisation  du  logiciel 

.  5  500  Kmots  de  logiciels  temps  reel,  la  documentation  de  1 'analyse-conception  et  de 
maintenance  correspond  ^  2,5  metres  dont  2  metres  de  listing  source. 

-  validation,  integration  systeme  : 

.  pour  la  validation  d’une  fonction  operationr.elle,  la  documentation  assoc'ee  represente 
I  metre. 


La  difficult^  de  mHe  au  point  de  ces  syst&fnes  et  1 'adequation  du  produit  final  realise  au 
vu  de  1 ‘expression  des  besoins  operationnels  se  traduisent  par  la  redaction  moyenne  de  3,5 
fiches  de  modification  par  jour,  ces  fiches  correspondant  i  des  demandes  de  correction  ou 
d'evolution. 


Pour  le  developpement  d'un  systeme  avionique,  le  temps  passe  sur  chacune  des  etapes, 
exprime  en  pourcentage  de  la  duree  totale  est  de  I'ordre  de  : 


-  phase  de  definition,  specification  systeme  304 

•  phase  de  realisation,  validation  equipement  50  % 

-  phase  d' integration  au  sol  20  i 

-  phase  d'essais  en  vol  10  % 


3  -  OBJECTIFS  PE  L'UTILISATIQN  D'OOTILLAGES  INFORMATIQl'ES 


La  complexite  du  developpement  des  sytemes  avioniques  justifie  pleinement  I'emploi  systematique 
d'outils  Informatiques  adaptes  pour  supporter  1 'ensemble  des  activites  du  cycle  de  vie. 

Get  ensemble  d'outils  comprend  des  "outils  de  fond"  pour  permettre  1 'acquisition  de 
connaissances  sur  les  fonctions  et  systemes  a  developper,  et  des  outils  formels  dont  le  r61e 
essentlel  est  de  fournir  une  aide  d  1 'application  d'une  methodologie  rigoureuse. 

Par  I'utilisation  d'un  ensemble  d'outils  informatiques  adaptes  aux  diff^rentes  stapes  du 
developpement,  les  objectifs  poursulvis  sont  les  suivants  : 


-  homogeneite  des  methodes  de  travail  par  I’utilisation  d’outils  communs, 

-  aide  i  la  definition  de  systemes  integres  et  evolutifs. 

-  obtention  de  specifications  de  qualite, 

•  amelioration  des  cormiunications  entre  les  differents  partenaires  oar  la  structuration 
et  la  formalisation  des  echanges. 

•  aide  S  1 'elaboration  de  la  documentation, 

-  reduction  des  coOts  et  des  deiais  par  : 


.  la  reuti 1 isation  issue  de  la  capitalisation  de  i 'experience, 

.  une  meilleure  productivite, 

.  une  minimisation  des  phases  de  validation/integration  lors  des  essais  au  sol  et  en 
vol  par  I'amel ioration  de  la  qualite  des  specifications  et  leur  validation  avant 
real isation. 


n  faut  noter  ici,  que  le  coefficient  d'ampl if icatioi'  des  couts,  pour  une  erreur  de  conception 
ou  de  specification  qui  n'est  decouverte  qu'aux  essais  au  sol  ou  en  vol,  est  de  I'ordre  de  50  a  100. 
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4  -  LE  CYCLE  DE  VIE  O'UN  DEVELOPPeKEKT  OE  SYSTEME  AVIONIQUE 


Au  cours  de  cette  presentation.  Ton  se  propose  de  dStailler  les  diffgrentes  Stapes  du  cycle 
de  vie  d'un  developpement  de  systSme  avionique  et  d'exprimer  les  besoins  associSs. 


4.1  -  PRINCIPALES  PHASES  DU  CYCLE  DE  VIE 


Au  vu  de  leurs  experiences  en  matiSre  de  d6veloppeflient  de  systSines,  et  pour 
repondre  aux  exigences  d'un  systSfne  avionique,  les  AMD-BA  se  sont  dSfinls  une  methoddogie  de 
dSveloppement  lHustree  par  le  cycle  de  vie  ci-aprAs. 


CYCLE  DE  VIE  DE  DEVCLOPPEkCVT  DES  5YSm£S  AVIOVIQUES 
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i 
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'NTtCWl’IOH 
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'Nf£o»A’;oii 

r>J10£MENT 


4.2  -  PHASE  DE  PRE-DEVELOPPEMENT 
4,2,1  -  Definition 


Lors  de  cette  phase,  les  buts  poursuivis  sont  principalement  : 

-  I'acquisition  de  la  connaissance  des  tnoyens  et  du  savoir-faire,  c'est-4-dire  le 
parcours  sur  la  possibilite  de  wise  en  oeuvre  de  nouveaux  apports  technologiques, 

-  L'evaluation  de  la  faisabilite  de  nouveaux  concepts  de  fonctions  operationnelles. 

Les  travaux  menfes  lors  de  cette  phase  sont  assimilables  4  des  travaux  de  recherche 
op#rationnelle,  d'^tudes  g^ngrales,  de  realisation  de  maquettes  probatoires  pouvant 
donner  lieu  4  des  simulations  partielles  ;  I'objectif  de  ces  travaux  est  de  rAunir  les 
elements  qui  permettront  de  definir  des  meilleurs  projets  de  systemes  et  d'etablir  les 
plans  de  developpement  techniques  et  industriels. 
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Cette  phase  fait  appel  i  de  nombreux  inter! ocuteurs  se  traduisant  notamment  par  : 

>  des  !iens  1ndustr1els-4quipement1ers  pour  !es  etudes,  la  technologie  de  base  et  la 
realisation  de  maquettes  probatoires, 

-  des  liens  industriels-avionneurs-equipementiers  pour  I'analyse  des  contraintes 
d'avionnage,  d'integration  systfeme  et  la  caracterisation  des  interfaces  de  dialogue 
equipage-systeme, 

-  des  liens  avec  les  centres  etatiques  pour  1 'evaluation  par  des  utilisateurs. 


4.2.2  -  Besoins 


Les  besoins  necessaires  dans  cette  phase  de  pr§-developne«**?nt  sont  essentiel lement 
des  "outils  de  fond"  perroettant  d'acquerir  une  connaissance  ;  ces  outils  reposent 
sur  des  : 

-  moyens  de  simulation  legers  ou  maquettage, 

•  moyens  de  simulation  luurds. 


4.3  -  PHASE  OE  DEPr»‘IfrOK 


4.3.1  -  Specifications  globales 


4. 3. 1.1  -  Definition 

A  partir  des  resultats  de  la  phase  de  pre-developpement  (etudes  de  faisabilite 
et  pre-etudes  de  performances)  et  des  besoins  operationnels  exprimes  par  la 
fiche  progranme,  cette  phase  a  pour  objectif  la  definition  preiiminaire  du 
systeme. 

Par  I'analyse  des  differentes  missions  dont  sera  capable  1 'avion,  il  est  precede 
au  recensement  des  fonctions  operationnelles  et  des  moyens  necessaires.  Cette 
etape  fait  une  premidre  description  des  fonctions  op^rationnel les ,  du  poste  de 
pilotage,  des  capteurs  et  de  1 'architecture  matferielle  sous  la  forme  de  specifications 
gfinSrales  fixant  le  cadre  des  travaux  5  rSaliser. 

A  Tissue  de  ces  travaux,  il  est  realise  un  document  "modes  et  commandes"  fournissant 
Tenveloppe  des  possibilites  du  systeme  avionique.  Ce  document  comporte  deux  parties 
orientees  "materiel"  et  "fonctionneT  : 

-  la  partie  "materiel"  presente  les  equipements  ou  sous-ensembles  du  systeme 
avionique,  ces  derniers  designant  les  capteurs  complexes  oossedant  differents  modes 
de  fonctlonnement  tels  que  radar,  capteurs  optroniques, 

-  la  partie  "fonctionnel"  presente  une  pbilosophie  generale  d'util isation  de  la  cabine 
(commandes  et  visualisations)  et  decrit  les  differents  modes  de  fonctlonnement  du 
systeme. 

A  partir  de  ce  document  "modes  et  commandes",  chaque  fonction  operationnel le  fait 
Tobjet  d'un  document  "specirication  globale"  traduisant,  en  termes  d'objectifs  fi 
atteindre,  le  scenario  operationnel  d'utilisatlon  :  les  moyens  d'activation,  les 
principales  commandes/actions  possibles,  les  visualisations  et  les  moyens  de  sortie  de 
la  fonction. 


4. 3. 1.2  -  Besoins 

Les  besoins  ressentis  pour  couvrir  cette  etape  sont  de  deux  natures  : 

-  moyen  de  validation  des  concepts  de  dialogue  Homme-machine  et  de  certains 
algorlthmes, 

Cette  validation  devra  recourir  i  des  outils  legers  de  simulation  mais 
offrant  une  restitution  suffisante  de  Tenvironnement  cabine  pour  permettre 
un  rebouclage  avec  des  utilisateurs  finaux. 

-  moyen  de  formalisation  des  rftsultats  des  travaux  pour  les  relectures  puis  le 
travail  aval  de  conception. 
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Pour  facIHter  les  relectures  documentaires  effectufees  par  un  grand  nombre 
d' intervenants»  la  forwalisation  doit  conserver  1 'util Isation  d'un  langage 
nature!  mais  garantir  rhontog^nfeiti  des  documents  par  le  respect  de  plan-types. 


4.3.2  -  Architecture  fonctionnelle 


4.3.2. 1  -  Definition 

A  partir  des  besoins  exprimes  lors  de  I'analyse  fine  des  scenarios  d'util isation 
des  fonctions  operationnelles,  des  hypotheses  de  mise  en  oeuvre  des  capteurs  et  de 
la  philosophie  d'utilisation  de  la  cabine,  cette  etape  a  pour  but  la  description  de 
I’architecture  fonctionnelle  du  systftme.  Le  rfisultat  attendu  est  un  dScoupage  du 
systeme  en  difffcrents  modules  fonctionnels  prenant  en  compte  des  regies  d'evolutivite. 
de  modularity,  de  recuperabilite  et.  resolvant  les  conflits  de  ressources  capteurs. 
commandes,  visualisations  liys  i  la  superposition  des  fonctions. 

Cette  architecture  met  en  yyidence  : 

-  les  chaines  fonctionnel les  par  le  cheminement  des  interfaces  entres  les  diff^rents 
modules . 

-  1 ' interdfipendance  des  fonctions, 

-  le  fractionnement  du  systdme  en  modules  fonctionnels  pour  lesquels  les  interfaces 
entrSes-sorties  sont  identifiys. 


4. 3. 2. 2  -  Besoins 

Cette  etape,  essentielle  pour  la  mattrise  des  systemes  et  particul iSrement  pour 
la  maitrise  des  evolutions  et  des  modifications,  justifie  le  recours  i  I'utilisation 
d'un  outil  formel  pour  garantir  la  visibility  du  systyme.  Le  fomalisme  recherchy  doit 
permettre  : 

1  -  Une  aide  3  la  conception  du  systyme  en  soutenant  la  dymarche  de  dycoupage, 

2  •  Une  Ifsibility  fonctionnelle  de  chacune  des  fonctions  opyrationnel les  au  sein  de 

I'architecture  compiyte. 

3  -  La  facility  d'exploitation  des  rysultats  pour  les  besoins  des  ytapes  avales. 

4  -  L 'amyi ioration  de  la  communication  entre  les  diffyrents  concepteurs  impliquys  dans 

la  dyfinition  de  I'architecture  fonctionnelle. 


4.3.3  -  Architecture  physique 


4.3.3. 1  -  Dyfinition 


Le  rysultat  de  la  prycydente  ytape  permet  de  disposer  d'une  connaissance  du  systyme 
sous  la  forme  d'un  ensemble  de  modules  fonctionnels  et  de  leurs  interfaces.  L'objet  de 
cette  ytape  est  de  projeter  cette  architecture  fonctionnelle  sur  I'architecture 
matyrielle  dyfinie  lors  de  la  phase  pryiiminaire  et,  par  iterations  successives,  de 
trouver  la  mellleure  repartition. 

Ainsi  les  diffyrents  modi  es  fonctionnels  sont  rypartis  dans  les  diffyrents 
yquipements,  ce  qui  permet  d’identificr  S  ce  stade  la  nature  de  transmission  des 
echanges  :  analogiques  ou  numyriques. 

L' affectation  de  ces  modules  aux  diffyrents  yquipements,  outre  les  evidentes 
affectations  au  vu  des  fonctions  premieres  des  yquipements ,  s'effectue  au  regard  des 
criteres  suivants  : 

-  yvolutivity,  charge  calcul  et  volume  memoire  des  processeurs,  dybits  des  echanges 
transitant  sur  les  bus,  ...  . 


4. 3. 3. 2  -  Besoins 


Au  cours  de  cette  fitape  de  superposition  de  Tarchitecture  fonctionnelle  sur 
V architecteure  matferie'le,  un  trfts  grand  nombre  d‘ informations  d'interfaces  est 
manipu1§  et  cette  manipulation  est  reconduite  1ors  des  multiples  Iterations.  Aussi 
1e  besoin  se  fait  ressentir  de  disposer  pour  ce  stade  de  definition  d'un  outi1  de 
gestion  dote  de  mecanismes  visant  i  automatiser  certaines  operations.  De  plus,  il 
convient  de  pouvoir  effectuer  une  validation  de  1 'architecture  physique  au  sens  des 
transmissions  numeriques  par  revaluation  des  charges  bus. 


4.3.4  -  Specifications  detainees 


4.3.4. 1  -  Definition 

Sur  la-base  des  resultats  des  etapes  amont,  est  etabli  un  ensemble  de  specifications 

qui  donneront  lieu  A  la  realisation  des  equipements  et  de  leurs  logiciels. 

Chaque  equipement  est  defini  par  les  specifications  suivantes  : 

-  Clauses  Techniques  d'lntegration  (CTI)  : 

.  Son  objet  est  de  definir  1 ' implantation  dans  I'avion,  les  contraintes  d'avionnage, 
le  rdle  de  1 'equipement  et  son  integration  au  sein  du  systeme. 

-  Specifications  Deta1116es  de  Fonctions  Operationnel les  (SDFO)  : 

.  Ces  documents  specifient  les  traitements  effectues  par  les  fonctions  logicielles 
dans  requipement  ;  pour  les  equipements  de  visualisations,  ces  specifications 
definissent,  de  plus,  la  symbologie  presentee  au  pilote. 

«  Fiche  d' Interface  Analogique  (FIA)  : 

.  Pour  chaque  liaison  analogique  de  requipement,  ces  fiches  specifient  la  nature 
du  cSblage  et  les  interfaces  eiectroniques  d'emission  cu  de  reception. 

-  Fiche  d' Interface  Oigibus  (FID)  : 

.  Ces  fiches  specifient  I'ensemble  des  conmunications  (echange,  frequence,  nature, 
codage,  ...)  de  requipement  via  le{s)  bus  avec  le  reste  du  systeme. 


4. 3. 4. 2  •  Besoins 

L'ensemble  des  produits  de  cette  etape  forme  le  noeud  de  cnomunicatio:.  entre 
I'avionneur-systemier  et  les  equipementiers.  Aussi  le  besjtn  essentiel  est 
d'etablir  la  meilleure  communication  possible  entre  tous  les  intervenants.  Cette 
recherche  de  la  meilleure  communication  conduit  4  des  formalismes  adapt#s  i  chacune 
des  specifications  et  3  I'utilisation  d'aides  pour  eliminer  les  ambiguTtes,  les 
omissions,  les  incoherences  ...  . 

Pour  accroltre  I'efficacite  et  limiter  les  decouvertes  tardives  d'anomalies  et  des 
erreurs  de  specifications,  le  besoin  s'exprime  en  termes  de  maquettage. 

Les  objectifs  du  maquettage  sont  les  suivants  : 

-  s'assurer  que  le  besoin  est  satisfait, 

-  donner  aux  concepteurs  des  moyens  de  verification  par  "une  animation  des 
specifications  papier"  pour  decouvrir  tres  tot  les  anomalies  fonctionnelles  ou 
les  erreurs  de  specifications, 

-  eiaborer  des  jeux  de  mise  au  point  qui  pourront  etre  rCutilises  lors  des 
premieres  validations  des  logiciels  reels, 

-  tester  et  vallder  les  evolutions. 

n  faut  noter  la  ’imite  de  cette  validation  qui  ne  peut  prendre  en  compte  les 
ressources  <**lculateurs  et  bus  qu’avec  une  notion  imparfaite  du  temps  ;  il  s'agit 
essentiellement  d'une  validation  fonctionnelle  des  specifications. 
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4.4  -  PHASE  DE  REALISATION 

4.4.1  -  O^finition*  Besoins 


L’ensemble  des  specifications  Issues  des  phases  precfidentes,  forme  1e  point  d'entree 
de  la  phase  de  realisation  des  equipements  et  des  logiclels. 

Pour  repondre  aux  exigences  croissa.ites  en  terme  dc  criticfte,  de  volutrte.  de 
multiplicite  des  versions  du  logiciel,  les  efforts  ont  porte  sur  la  methodologie,  le 
gain  en  prQductiv1te»  1 'automatisation  du  processus  de  developpement  ;  en  particulier, 
la  phase  de  realisation  est  subdivisee  en  sous-phases  ou  activites  formalisees,  et 
pouvant  etre  validees  avant  le  passage  4  la  phase  suivante. 

Aussi  pour  repondre  4  ces  objectifs»  il  convient  de  supporter  I'ensemble  des  etapes  de 
realisation  des  logiciels  par  un  ensemble  d'outils  coherents  et  adaptes  ;  ces  etapes 
sont  : 

-  Definition  de  logiciel. 

-  Conception  de  logiciel. 

-  Codage  sur  des  chatnes  de  prograirmatlon  utllisant  plusleurs  langages  pour  repondre 
au  mieux  aux  contralntes  des  differents  programnes  operatlonnels. 

-  Tests  statiques  et  dynamiques. 


4.5  -  PHASE  DWNTEGRATION  ET  DE  MISE  AU  POINT 


Apres  la  realisation  des  equipements  et  leur  validation  unitaire  chez  les  differents 
industriels,  la  notion  de  systeme  va  devenir  effective.  La  premiere  etape  de  validation,  h 
ce  stade,  concerne  les  travaux  d'integratlon  effectues  sur  les  "bancs  d' integration 
systeme" . 

Un  banc  d'integratlon  systeme  se  definit  comme  un  moyen  de  stimulation,  i  partir  d'enre- 
glstrement  de  vols  reels,  de  I'ensemble  des  equipements  du  systeme  cables  sur  le  cablage  reel 
de  I'dvlon. 

Le  but  de  ces  bancs  d'integratlon  est  la  validation  et  la  mise  au  point  du  systeme 
avionique  et  done  de  ses  fonctions  operationnelles,  dans  un  environnement  et  une  configuration 
realistes,  aux  fins  de  limiter  le  nombre  des  essais  en  vol . 


4.6  -  ESSAIS  EN  VOL 


Les  essais  en  vol  sont  la  phase  finale  de  validation  des  systSmes  avioniques. 


4.7  -  L ’ASPECT  OES  EVOLUTIONS 

4,7.1  -  Origine 


Les  demandes  d'evolution  trouvent  leur  origine  i  deux  niveaux  : 

-  les  evolutions  demandees  pour  que  le  systeme  satisfasse  au  mieux  aux  besoins 
operatlonnels  initialement  exprimes  dans  la  fiche  prograirme  :  ce  sont  les  demandes 
de  modifications  et  d 'ameliorations  issues  des  phases  de  mise  au  point  et  de 
validation  sol,  vol. 

-  1es  evolutions  demandees  pour  que  le  systeme  satisfasse  3  de  nouveaux  besoins 
operatlonnels  ;  ce  sont  les  demandes  d'evolutions  correspondant  3  de  nouvelles 
demandes  clients. 

Dans  les  deux  cas,  le  traitement  sera  identique,  comme  indique  ci-apres  : 


4.7.2  -  Procedure 


Toute  demande  ou  proposition  d'evolution  se  traduit  par  I'ecriture  d'une  fiche 
de  modification  etablle  en  termes  operatlonnels  au  niveau  systeme. 

Cette  fiche  de  modification  systeme  est  injectee  dans  le  cycle  de  vie  de 
developpement  au  niveau  approprie  pour  y  etre  instruite  ;  cette  instruction 
permet  d'etablir  I'ensemble  des  fiches  d'evolution  pour  chacun  des  produits 
constituent  le  systeme  et  touches  par  cette  evolution. 
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Une  fois  instruites,  ces  fiches  de  modifications  syst^me  sont  proposecs  Tors 
de  conferences  techniques  qui,  au  regard  des  couts*  des  deials  et  de  I'interet 
operationnel t  deddent  de  ieur  application. 

Lors  du  developpement,  c*est  par  le  bials  de  ces  conferences  techniques  que 
le  systeme  avionique  evolue  en  differents  "etats  systeme  de  developpement" 
jusqu'd  I'etat  operationnel  appeie  "ctandard**.  De  facon  identique,  le 
systeme  operationnel  evolue  de  standard  en  standard  pour  repondre  a  de  nouveaux 
besoins  clients. 


4,7.3  -  besoins 

Au  regard  des  evolutions*  le  besoin  s'exprime  par  : 

“  gerer  de  facon  rigoureuse  les  d«nandes  d'evolution  et  leur  suivi, 

-  maintenir  a  jour  I'ensemble  de  la  documentation  de  specification, 

-  etre  capable  de  consulter  la  definition  de  cheque  "etat  systeme". 


5  -  TRAVAUX  ITI 

5.1  -  PRESENTATION 


Dans  le  cadre  du  cycle  de  vie  de  developpement  d'un  systeme  avionique  et  du  fait  de 
I'accroissement  nature!  des  relations  entre  toos  les  cooperants  participant  au  developpement 
de  systeme  (avionneurs,  equipementiers,  centre  d'essais  en  vol .  Ministere  de  la  Defense,  ...) 
11  est  apparu  necessaire  de  mieux  organiser  et  renforcer  ces  relations  plus  particul lerement 
pour  tout  ce  qui  concourt  3  la  conception  du  systeme,  h  la  production  et  e  la  maintenance  des 
logiciels. 

L'etude  ITI  (Integration  et  Traitement  de  T Information)  rassemble  des  ind-.istriels 
avionneurs  (AEROSPATIALE  et  AVIONS  HARCEL  DASSAULT  -  BREGUET  AVIATION)  et  equipementiers 
(CfiOUZET.  ELECTRONIQUE  SERGE  DASSAULT,  SAGEM,  SEIM,  SFENA,  THOMSON-CSF)  dejl  entralnes  4 
cooperer  depuis  de  nombreuses  annees  pour  realiser  des  systemes  avioniques,  ce  qui  permet 
de  proposer  de  facon  conwune  la  realisation  d'un  systeme  de  developpement  d'avionique  (SOA) 
qui  permette  en  particulier  de  formaliser  les  relations  entre  les  industrials  cooperants 
permettant  ainsi  d'assurer  une  meilleure  qualite  4  un  cout  moindre  et  de  profiter  des 
competences  et  experiences  acquises. 


5.2  -  HISTORIQUE 


Au  cours  de  I'annee  1983,  sur  la  constation  de  1 'apparition  systematique  des  logiciels 
dans  les  equipements  et  1 ' integration  de  plus  en  plus  grande  des  differentes  fonctions, 
retude  ITI  a  oriente  ses  travaux  vers  la  realisation  d'un  svsteme  de  developpement  avionique. 
Cette  orientation  repondait  au  besoin  de  mattriser  les  deiais  et  assurer  la  qualite  des 
systemes  et  plus  particulierement  le  developj^ent  des  logiciels.  Le  logidel,  par  son 
interchangeabilite  et  son  cout  de  production  en  serie  quasiment  nul,  a  permis  de  reoorter  sur 

lui  des  modifications  qui  auraient  ete  longues  et  couteuses  d'introduire  dans  la  partie 

materielle.  Cependant,  aprSs  quelques  annees  d'experience,  les  industriels  aferonautiques  se 
sont  apercus  que  cette  souplesse  du  logiciel  et  son  introduction  massive  mal  maitrisee 
pourraient  presenter  dcs  risques  graves. 

Les  premiers  travaux  engages  ont  permis  d'etablir  un  cadre  methodologique  cownun,  synthese 
d'un  questionnaire  presentant  les  methodes  et  outils  de  chacune  des  soci§tes.  Un  cycle  de  vie 

standard  a  ete  etabli  mettant  en  evidence  chacune  des  phases  et  les  activites  associees.  Pour 

chaque  phase,  1 'analyse  en  matiere  d'outillage  a  ete  conduite  sous  les  angles  : 

-  offrir  au  concepteur-developpeur  une  aide  4  la  nature  de  I'activite  qu'il  exerce, 

-  offrir  des  moyens  de  communication. 

Ces  travaux  se  sont  concretises  debut  par  un  document  de  specifications  globales  du  SDA. 

A  Tissue  de  ces  travaux  finalisant  Texpression  des  besoins  et  4  partir  de  Tevaluation 
d'un  grand  nombre  d'outillages  existants,  la  solution  retenue  a  conduit  4  la  definition  de  2 
ateliers  integres  ;  Un  Atelier  Systeme  et  un  Atelier  logiciel  conwuniquant  entre  eux. 

L'Atelier  Systeme  couvre  les  phases  de  conception  et  de  definition  de  systeme,  TAteller 
Logiciel  les  phases  de  conception  et  de  developpement  logiciel. 
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D'autre  part*  Tateller  ne  pas  seulement  des  documents  (nais  aussi  les  informations 
contenues  dans  ces  documents  ;  1‘atelier  est  caract6r1s6  par  un  grand  formalisme  des  outHs 
permettant  d'acc^der  aux  donn^es  manlpul^es  entre  outHs  et  la  base  de  donn^es  de  r6f§rence. 
L'ateller  intigrd  a  I'avantage  de  fournir  une  vision  globale  et  coh#rente  du  projet*  une 
reduction  du  volume  d' Informations  avec  une  plus  grande  fiabilit^  de  ces  informations  et  une 
autumatlsatlon  des  contrdies. 

La  solution  retenue  a  fait  I'objet  de  la  redaction  d'une  Specification  Oetailiee  du  SOA 
fin  85. 

II  faut  noter  que  la  particularite  de  ces  ateliers  est  d'etre  "ouverts",  au  sens  ou  chaque 
industrial  peut  completer  et  integrer  ses  outils  propres  afin  d'assurer  une  tneilleure 
couverture  du  cycle  de  vie. 


6  -  SPA  ITI 


Nous  nous  proposons  ci*dessous  d’introduire  la  definition  des  Ateliers 
Systeme  et  Logiclel  ;  une  presentation  plus  precise  faisant  I’objet  d'une  seconde 
presentation  ;  ATELIER  OE  CONCEPTION  OE  SYSTEME  AVIONIQUE  ET  OE  REALISATION  DE  LOGICIEL 
EHBARQUE. 


6.1  -  ATELIER  SYSTEME 


II  s'agit  de  I'ensemble  des  outillages  mis  en  place  pemettant  i  1 'Atelier  Systeme 
de  gerer  : 

-  la  logique  de  developpement  du  systeme* 

>  les  dialogues  avec  tous  les  intervenants, 

•  les  demandes  d'evolution  d'un  systeme  en  developpement, 

-  les  activites  de  conception  et  de  definition  systeme  supportees  par  des 
outils  adaptes. 
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6.1.1  -  Structure  d'Accuell  syst^e 


La  Structure  d'Accueil  Systfeme  assure  les  fonctSons  de  : 

-  initialisation  de  projet 

-  suivi  des  Evolutions 

“  gestion  de  configuration  systEme 

-  intEgration  des  outfis  spEcifiques  de  I'atelier 

-  administrateur  gErant  les  droits  d'accEs. 

Plus  particul iErement  son  rdle  a  pour  objet  : 

-  TintEgration  des  diffErents  outils  de  1 'Atelier  SystEme  par  des 
Echanges  standards  d' informations  entre  un  outil  amont  et  un  outil  aval, 

-  la  gestion  de  1 'ensemble  de  la  documentation  de  spEcification  du  systEme, 

-  la  gestion  du  plan  de  dEveloppement. 

-  la  gestion  des  cocmunications  entre  les  diffErents  partenaires, 

-  par  rapport  d'un  outil  de  documentation,  elle  assure  la  composition  des 
rEsultats  des  diffErents  outils  pour  VElaboration  de  la  documentation  de 
SpEcification  du  systEme* 

-  la  gestion  du  suivi  des  Evolutions  et  la  garantie  de  la  cobErence  de  I'ensemble 
des  produits  de  spEcification  Issus  des  outils  par  la  gestion  de  rapplication 
de  mEcanistnes  au  niveau  de  chacun  des  outils  de  1 'Atelier  assurant  : 

.  1 ' instruction  de  la  modification  sous  1 'outil  tout  en  conservant  I'Etat 
"avant"  de  la  modification, 

.  la  mesure  de  I'impact  de  la  modification  par  le  contrble  de  la  modi¬ 
fication  en  elle-mEffie  et  vis-E-vis  de  la  spEcification, 

.  la  rEdaction  automatique  de  la  fiche  d'Evolution. 


6.1,2  -  Outil  de  Conception  SystEme  (OCS) 


La  phase  de  dEfinition  est  couverte  par  un  outil  en  cours  de  dEveloppement  OCS 
(Outil  de  Conception  SystEme). 

II  supporte  graphiquement  une  mEthode  d'analyse  hlErarchique,  structurEe  et 
descendante  pennettant  d'apprEhender  des  systEmes  complexes  de  maniEre  gEnErale 
et  d'en  dEcouvrir  les  dEtails  au  cours  de  I'Etudc. 

Cet  outil  reprend  un  certain  nombre  de  concepts  de  la  mEthode  IDEFO  auxquels  ont 
EtE  adjoints  de  nouveaux  concepts  pour  : 

-  aider  E  la  dEfinition  d’interfaces  effectuEs  simultanEment  par  plusieurs 
concepteurs, 

-  identifier  les  diffErentes  chalnes  fonctionnel les, 

-  apporter  des  mEcanismes  de  rEcupErabilitE. 


6.1.3  -  Outil  commande  de  dEfinition  assistE  par  ordinateur  (DLAO) 


La  phase  de  spEcification  dEtaillEe  est  couverte  par  un  outil  en  cours  de 
dEveloppement  DLAO  (DEfinition  de  Logiciel  AssistEe  par  Ordinateur).  Cet 
outil,  utllisE  pour  1 ‘Elaboration  de  spEcifications  de  logiciel  temps 
rEel *  permet  : 

-  d'accroltre  la  qualitE  des  spEcifications  par  un  langage  formel  associE 
4  des  contrbles  afin  de  limiter  les  erreurs  de  type  ambiguTtE,  omission, 
incohErence,  surspEcification,  ..., 

-  d'amEllorer  la  cowminication  par  la  production  de  documents  fiables  et 
adaptEs  aux  besoins  des  diffErents  intervenants. 


6.1.4  -  Un  outi1  de  specification  assist^  par  ordinateur  (SAO) 


En  phase  de  specification  detainee,  un  outil  compietnentaire  SAO  (Specification 
Assistee  par  Ordinateur)  est  utilise. 

Utilisant  un  outil  de  CAO  schematique,  cet  outil  permet  la  specification  sous 
la  forme  de  planches  graphlques  des  lialslons  Inter-equlpements  sans  prejuger 
de  la  realisation  (materiel  ou  logiciel)  ;  ces  planches  sent  utllisees  convne 
support  de  communication  entre  les  dlfferents  partenaires. 


ATELIER  LOGICIEL 


Les  solutions  de  1' Atelier  Logiciel  sont  proches  de  1 'Atelier  Systeme  en  ce  qui  concerne  les 
fonctionnal Ites  :  .I'on  trouvera  une  Structure  d'Accueil  assurant  la  gestlon  de  configuration,  le 
sulvi  des  evolutions,  1 ' integration  des  outils,  le  r61e  d'administrateur  et  des  outils  specifiques 
pour  couvrir  les  etapes  de  definition  logiciel,  conception  logiciel,  differentes  chafnes  de 
progranvnation  et  des  outillages  de  test. 

Ce  proJet  ENTREPRISE  d'atelier  logiciel,  developpe  sous  la  tutelle  du  Ministere  de  la  Defense, 
est  decrit  dans  la  seconde  presentation. 


UTILISATION  DE  L'ATELIER  SYSTEME  AUX  AHD/BA 


Le  coeur  de  I'Atelier  Systeme  AM0-8A  est  constitue  de  I'Atelier  Systeme  ITl  et  de  I'ensemble 
des  outillages  coinnuns  auxquels  ont  ete  adjoints  un  certain  nombre  d'outlls  propres  de  maniere  i 
assurer  une  meilleure  couverture  de  certalnes  etapes  du  cycle  de  vie. 

Nous  presenterons  ci-dessous  les  outils  comp! ementa ires  puis  un  schema  iUustrant  le  support 
apporte  par  I'ensemble  des  outils  utilises  aux  AHD-BA  au  cycle  de  vie  complet  de  developpement. 


8.1  -  OUTILS  SPECIFIQUES  AMO-BA 


8.1.1  -  Outil  d'etude  amont 


La  phase  de  specification  globale,  s'appuie  sur  un  outil  infonnatique  OASIS  (Outil 
d'Aide  i  la  Specification  d'Interface  Homme-Systeme) . 

Cet  outil  permet  la  simulation  pilotee  de  fonction  operationnelle,  representative 
des  commandes  et  visualisation  de  la  cabine,  pour  retude  et  1a  validation  du  dialogue 
Homme-machine  et  de  certains  algorithmes. 

Tres  souple  d'utilisation,  facile  de  mise  cn  oeuvre  et  rapide  pour  Texecution  de 
modifications,  cet  outil  d’etude  offre  un  rebouclage  rapide  et  efficace  entre  les 
concepteurs  et  les  utilisateurs  et  ce,  des  le  niveau  des  premieres  definitions. 


8.1.2  -  Outils  formels  compiementaires 


Phase  architecture  physique 

Un  outil  specifique  OEA  (Outil  d'Etude  d'Architecture) ,  en  cours  de  realisation, 
permet  de  courvir  cette  etape.  II  assure  une  validation,  au  sens  des  transmissions 
numeriques,  de  1 'architecture  ainsi  definie  par  revaluation  des  charges  bus. 


Phase  specification  detailiee 

-  Un  outil  de  specification  d'imagerics  avioniques  MITIA  (Moyens  Informatiques  pour  le 

Traitement  des  Imageries  Avioniques)  : 

.  Cet  outil  se  presente  dans  un  environnement  de'CAO  (Conception  Assistee  par 
Ordinateur)  dont  un  ensemble  de  fonctions  est  particularise  et  enrichi  pour  cette 
utilisation  ;  il  permet  de  specifier  par  creation  ou  modification  des  reticules  ou 
des  figurations  completes. 

.  Le  resultat  issu  de  cet  outil  presente  la  specification  sous  la  forme  d’edition 
papier  ou  d’un  fichier  informatique  dit  "neutre"  (fichier  independant  des  machines 
graphlques)  ;  ce  fichier  par  son  formalisme  et  sa  "neutralite",  tisse  un  reseau 
permettant  une  coffmunication  aisee  entre  les  concepteurs,  les  centres  de 
simulation  et  les  equipementiers  charges  de  realiser  le  logiciel  de  visualisation. 
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-  Uf)  outTi  de  specification  du  ciblage  avion  et  des  fiches  d' interfaces  analogiques 
SYNOPTICS  : 

.  BSti  autour  d'un  logiciel  de  CAO  schematique  eiectrique,  cet  outi1  permet  1a 
saisie  des  plans  synoptiques  de  cablage  avion  et  la  realisation  des  fiches 
d’interfaces  analogiques  ;  il  verifie  les  liaisons  eiectriques  au  regard  des 
regies  de  Vart  et  contrdle  la  coherence  de  I'ensemble  de  1a  liasse  schematique. 

-  Un  outil  de  specification  des  fiches  d'interfaces  numeriques  GIN  {Gestion  des 
Interfaces  Numeriques)  : 

.  Cet  outil  supporte  la  specification  des  echanges  entre  les  cifferents  equipements 
selon  1 'architecture  numerique  composee  d'un  ou  plusieurs  bus  et,  i  partir  des 
procedures  de  gestion  d'Achanges  de  type  GINA,  1553-B,  ARINC. 


8.2  -  COUVERTURE  DU  CYCLE  0£  VIE 


Au  regard  du  cycle  de  vie  du  developpement  d'un  systeme  avionique,  la  couverture  de 
1 'Atelier  Systeme  precedemment  exposee  se  synthetise  par  1e  schema  suivant  t 

ATELIER  SYSTEME  DANS  LE  CYCLE  DE  VIE 


9  -  EXPERIEWCES  PARTIELLES  ;  CONCLUSION 

Un  certain  nombre  d'outillages  infonnatiques,  prefigurant  cet  Atelier  Systeme,  ont  dejS  ete 
utilises  pour  1e  developpement  de  nos  recents  systemes  avioniques.  Leur  utilisation  a  permis  de  nous 
conforter  dans  la  definition  de  I'Atelier  Systeme  par  I'apport  de  gains  tels  que  : 

-  I’amei ioration  des  communications  entre  les  partenaires  industriels, 

-  la  meilleure  qualite  des  specifications, 

-  1'aide  apportee  au  suivi  de  la  definition  du  systeme. 

Oe  plus,  ces  experiences  ont  mis  1 'accent  sur  ; 

-  la  recherche  de  1a  meilleure  convivialite  de  ces  outils  pour  ameiiorer  la  productivite, 

-  le  besoin  d' integration  de  ces  outils  entre  eux, 

'  I'aide  apportee  par  ces  outils  par  la  mise  e  jour  de  la  documentation  des  specifications. 


L'ensemble  de  cette  demarche  est  analogue  i  cellc  qui  a  et6  menee  en  matiere  de  CAO-CFAO  ces 
dernieres  annees  et  qui  a  conduit  i  la  realisation  de  grands  produits  logiclels  tel  le 
logiciel  CATIA  (Conception  Assistee  Tridimenslonnel le  Inter-Active),  realise  aux  AMO-BA. 

Convaincus  au  sein  de  la  conmunaute  avionique  francaise  du  besoin  de  disposer  d’un  Atelier 
Systeme  pour  le  developpement  des  nouveaux  pro9raiir<es,  nous  avons  lance  le  developpement  de  cet 
atelier  en  vue  d'aboutir  e  sa  realisation  au  debut  89. 
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StmARY 

Under  sponsorship  of  the  U.S.  Air  Force  Rome  Air  development  Center  (RADC),  a 
Software  Engineering  Environment  known  as  the  Software  Life  Cycle  Support  Fivironment 
(SLCSE)  was  specified  and  is  currently  undergoing  a  24  month  advanced  development. 

The  SLCSE  is  a  distributed,  computer-based  environment  of  software  development 
tools  and  methods  which  span  the  full  spectrum  of  the  software  life  cycle  and  are 

integrated  through  a  common  and  consistent  user  interface  and  a  life  cycle  project 

database.  Primary  features  of  the  SLCSE  are:  (1)  it  supports  both  the  development  and 

management  of  complex  mission-critical  computer  resources  (MCCR)  software  systems  in 
accordance  with  the  DoD-STD-2167  life  cycle  model  for  software  development ,  12}  it  ’  ? 

multi-lingual  -  supporting  the  Air  Force  standard  higher-ofder  languages  includit.g 
MIL-STD-1 589B  (JOVIAL  J73)  and  M I L-STD- 18 1 5A  (Ada),  and  (3)  through  its  unifying 
framework,  it  enables  the  integration  of  both  newly  developed  and  existing 
(off-the-shelf)  software  tools.  This  paper  will  present  the  SLCSE  development  effort, 
including  highlights  of  the  SLCSE's  architecture,  requirements  and  top-level  design. 
The  implementation  approach,  which  consists  of  a  series  cf  eight  incremental  builis, 

will  be  described  along  with  the  results  of  the  first  build.  Testing  and  verification 
plans  will  be  discussed  and  risk  areas  identified.  Finally,  long-term  plans  by  RAPC  to 
evolve  the  SLCSE  beyond  the  current  contractual  requirements  will  be  indicated. 

1  HTTRODUCTION 

The  Software  Life  Cycle  Support  Eiivironment  (SLCSE)  is  a  collection  of  integrate! 
tools  operating  on  a  Digital  Equipment  Corporation  VAX/VMS  computer  that  will  support 
the  production  of  MCCR  software  throughout  its  entire  life  cycle.  The  tools  are 
embedded  in  a  framework  consisting  of  a  user  interface  and  a  database.  At  the  highest 
level,  integration  of  tools  is  brought  about  by  this  framework,  which  provides  a  commmon 
"look  and  feel"  for  all  of  the  tools  and  provides  access  to  all  data  available  to  a 
SLCSE  user. 

Supplementing  this  level  of  integration  are  the  user  assistance  features,  which 
include  tailorable,  knowledge-based  software  development  methodology  direction,  in 
addition  to  the  usual  on-line  information  regarding  details  of  tool  operations. 
Finally,  at  the  detail  level,  the  tools  are  integrated  in  a  particular  instance  of  the 
environment  by  the  specific  management  and  development  methods  that  are  incorporated 
into  the  knowledge-base  and  the  specific  database  entities  that  are  incorporated  int 
the  overall  database  schema.  These  data  inputs  are  tailored  to  the  project  and  project 
management  parameters  such  as  the  life  cycle  model  of  the  project,  the  project  size,  the 
skills  and  experience  of  project  personnel,  and  so  on. 

1.1  Features 

The  principal  features  of  SLCSE  that  address  the  needs  of  MCCR  software 
development  across  its  life  cycle  (regardless  of  the  life  cycle  model  chosen)  are  as 
fol lows : 

Completely  Integrated  Toolset.  The  project’s  needs  for  the  entire  life  cycle  arc 
met  by  TntegratTng  a  completTe  toolset  in  support  of  critical  life  cycle  activities. 
Additionally,  individual  users  will  be  identified  by  the  role  they  are  currently  playing 
and  directed  to  the  proper  tools  and  action  sequences  for  performing  role  functions. 

Flexible  Development  Methodology.  The  SLCSE  will  allow  software  development 
methodology  to  be  spec! /Ted  by  the  project  manager.  Consequently  the  individual  usr 
roles  can  be  delineated  in  decail,  including  differing  levels  of  control  for  different 
roles.  If  the  specified  methodology  permits  a  certain  amount  of  trial-and-error 
development  for  certain  user  roles,  SLCSE  can  be  instructed  not  to  issue  error  messages 
if  a  set  of  tools  is  not  used  in  a  particular  order.  However,  if  a  well-defined  set  of 
procedures  is  to  be  followed  by  another  class  of  users,  SLCSE  can  be  set  up  to  enforce 
those  procedures  exactly  as  defined. 

Development  and  Management  Support.  The  needs  of  MCCR  software  project  managers 
will  be  addressed  by  the  SLCSE.  Project  management  planning,  scheduling,  and  costing 
aids  as  well  as  problem  reporting  and  status  monitoring  tools  will  be  supplied. 
Configuration  management  tools  will  also  be  in  place  to  support  both  software  developers 
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and  managers.  As  the  repository  of  all  project  information,  the  project  database  will 
provide  management  with  data  for  tracking  the  development  that  is  asually  difficult  or 
impossible  to  gather. 

Support  for  Automated  Document  Preparation.  A  major  problem  of  life  cycle  support 
is  maintenance  of  documentation,  making  it  consistent  with  the  current  software  product 
and  not  several  versions  behind.  The  concept  of  enforceable  methodology  (including  the 
enforced  documentation  of  changes),  the  total  availabixity  of  all  project  information  in 
a  common  database,  and  t  .2  use  of  docomen*  generation  and  updating  tools  will  permit 
SLCSE  to  provide  complete  and  timely  documentation  throughout  the  life  cycle. 

1.2  Development  Team 

General  Research  Corporation  (GRC)  is  the  prime  contractor  for  developing  the 
SLCSE.  Subcontractors  are  Intermetrics,  Inc.  of  Cambridge,  Massachusetts,  and  Software 
Productivity  Solutions,  Inc.  of  Melbourne,  Florida.  Development  is  funded  by  the  US  Air 
Force  Systems  Command  through  the  Rome  Air  Development  Center  (RADC).  The  design  is 
based  on  a  definition  study  previously  sponsored  by  RADC  and  performed  by  GRC  teamed 
with  Intermetrics . 

2  SLCSE  ARCHITECTURE 

2.1  Project  Objectives 

The  long-term  development  of  SLCSE  will  be  an  evolutionary  process.  The  current 
contract  will  produce  a  series  of  eight  builds,  two  of  which  will  be  delivered  to  RADC 
during  the  course  of  the  project  as  intermediate  "proof  of  concept"  versions.  The  final 
build,  SLCSE  3.0,  will  be  delivered  as  the  end  product  of  the  project,  and  will  have  a 
toolset  capable  of  supporting  the  full  DoD-STD-2167  life  cycle.  More  importantly, 
however,  this  version  will  demonstrate  the  integrated  environment  principle,  producing  a 
framework  for  the  continued  evolution  of  the  SLCSE  toolset.  SLCSE  3.0  will  provide  a 
usable  life  cycle  environment,  capable  of  supporting  MCCR  software  projects.  It  will  be 
complete  with  respect  to  the  framework  and  integration  concepts  that  have  been 
identified  as  essential  to  Meeting  the  goals  of  productivity  and  quality  and  will  offer 
a  respectable  catalog  of  tools. 

2.2  Architecture  Overview 

Figure  2.1  shows  the  overall  SLCSE  architecture,  and  the  relationship  of  the  three 
subsystems . 


Figure  2-1.  SIXISE  Subsystems. 
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User  Interface.  The  primary  goal  of  the  user  interface  is  to  provide  a  single 
shell  to  the  user  for  communicating  with  all  tools  in  the  SLCSE,  for  transferring  data 
within  the  SLCSE,  and  for  getting  assistance  on  the  use  of  tools  and  the  environinent 
itself.  The  project  will  produce  a  standard  set  of  user  interface  packages  that  will  be 
supplied  to  builders  of  new  tools  along  with  guidelines  for  developing  tools  that  match 
the  desired  interface  principles.  In  SLCSE  3.0,  invocation  of  an  existing  tool  will 
adhere  to  the  SLCSE  user  interface  principles,  but  once  invoked  the  tool  will  continue 
to  use  its  current  command  language  or  menu  systems.  When  off-the-shelf  tools  are 
updated,  they  will  be  reviewed  to  determine  the  feasibility  of  redesigning  their  user 
interfaces  to  the  SLCSE  standards. 

Database .  As  with  the  user  interface,  the  database  subsystem  for  SLCSE  3*0  will 
emphasize  the  development-  of  packages  that  will  support  the  long-term  goals  of  a  fully 
integrated  toolset.  Interface  routines  will  permit  existing  tools  to  make  use  of  the 
SLCSE  database,  but  databases  or  data  files  generated  by  these  tools  will  not  be 
replaced  in  SLCSE  3.0.  New  tools,  however,  will  communicate  directly  with  the  database, 
following  guidelines  published  for  using  the  database  subsystem  utilities.  In  the 
future,  tools  having  their  own  internal  databases  may  be  redesigned  for  use  of  the  SLCSE 
database  utilities,  but  that  is  likely  to  result  in  a  more  sweeping  redesign  than  would 
be  required  for  changing  the  user  interface  of  an  existing  tool. 

Toolset.  Users  must  perceive  SLCSE  as  a  unified  collection  of  tools  that  work 
efficiently  together.  Tools  that  are  added  to  the  environment  must  be  integrated  into 
it  either  by  <lesigning  them  that  way,  or  by  using  the  facilities  of  the  user  interface 
and  database  subsystem  to  provide  the  integration. 

The  goal  criteria  for  integrating  the  toolset  are  as  follows: 

(1)  Similarly  invoked  functions  must  operate  from  a  uniformly  similar  user  interface. 

(2)  User  assistance  must  be  provided  in  a  uniform  manner  for  all  tools. 

(3)  Tools  that  communicate  data  to  another  tool  must  provide  it  completely,  and  in  a 
uniform  format  that  all  tool  builders  will  u&5. 

(4)  Tools  must  provide  management  data  in  a  uniform  format  to  the  management  to'-^ls. 

The  degree  to  which  these  integration  goals  can  be  achieved  depends  on  the  degree 
to  which  tools  are  "coupled"  to  the  user  interface  and  database  utilities. 

(1)  Directly  coupled  tools  wi’l  access  the  user  interface  and  the  database  by  calling 
their  utilities  directly  to  send  and  receive  data,  and  will  adhere  strictly  to  the 
integration  goals, 

^21  Indirectly  coupled  tools  will  generally  communicate  with  the  user  interface  and 
the  database  through  intermediate  files,  l<iqical  names,  and  global  symbols  that 
are  set  up  by  interface  routines  and  command  procedures. 

It  is  aenerally  not  possible  to  integrate  existing  tools  under  the  above  criteria. 
SLCSE  3.0  will  call  on  the  framework  (i.e.,  the  user  interface  and  the  database  system} 
to  provide  the  mechanisms  for  integrating  such  tools.  This  will  be  accomplished  as 
£ol lows : 

(1)  Command  interpreters  and  interface  routines  can  be  used  to  meet  the  top-level  user 
interface  requirements,  user  assistance  requirements,  and  the  tool-to-tool 
communication  requirements. 

(2)  Commands,  menus,  and  help  features  that  are  already  built  into  existing 

interactive  tools  will  be  used  as  is  until  the  maturation  of  the  SLCSE  brinas 

about  the  desired  tool  modification,  or  the  introduction  of  new  tools  tailored  to 
the  environment. 

The  SLCSE  3.0  toolset  will  be  largely  assembled  from  existing  tools,  drawing  on 

interface  routines  to  provide  integration  at  the  tool  invocation  level.  Internal 

communications  with  the  user  and  with  data  files  will  not  be  modified.  This  produces 
some  compromises  with  respect  to  long-term  toolset  integration  goals,  but  no  compromises 
will  be  made  in  the  framework  itself. 

Several  new  tools  will  be  fully  integrated  into  SLCSE  3.0.  These  include  tools 
built  under  the  SLCSE  contract,  and  the  Ada  Test  and  Verification  System  (ATVS),  which 
was  designed  under  a  RADC  contract,  and  is  now  in  its  implementation  phase. 

In  contrast  to  SLCSE  3.0,  later  versions  of  SLCSE  will  strive  for  direct  couplina 
of  all  tools.  New  tools  will  be  built  for  direct  coupling,  using  standard  packages  for 
communicat i.ng  with  the  user  interface  subsystem  and  database  subsystem  that  will  be  made 
available  t-j  tool  developers  as  a  part  of  their  implementation  contract.  If  an  existing 
tool  has  a  desired  capability,  it  will  be  modified  for  direct  coupling,  or  if  that  is 
not  possible  due  to  the  design  cf  the  tool,  it  will  be  recoded  using  the  standard 
interface  packciges .  Indirect  coupling  in  later  builds  will  be  used  primarily  for 
evaluation  of  an  existing  tool  to  determine  if  its  capabilities  warrant  including  it  as 
a  regular  (and  thus  directly  coupled)  component  of  the  environment  toolset. 
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3  SLCSB  REQUIRBtEMTS 

The  SLCSE  is  a  very  complex  system  and«  as  such,  has  a  complex  set  of 
requirements.  However,  the  top  level  requirements  forth  in  this  section  are 

relatively  easy  to  describe. 

3.1  User  Interface  Requirements 

Easy  to  use.  The  SLCSE  must  make  use  of  Man-Machine-Interface  (MMI)  techniques 
that  promote  user-friendly  operations,  such  as  the  use  of  multiple,  overlayed  windows 
and  the  consistent  use  of  various  regions  of  the  screen.  Of  course,  what  is 
user-friendly  for  the  novice  might  be  very  frustrating  for  an  individual  familiar  with 
SLCSE  operations.  Therefore,  this  requirement  also  dictates  that  t>>e  ST.CSE  must 
comfortably  support  users  of  all  types,  providing  a  spectrum  of  command  alternatives 
from  menu  hierarchies  to  cryptic,  keyword  phrases. 

Supports  user  roles.  The  SLCSE  framework  must  support  the  nineteen  user  roles 
depicted  in  Figure  3-1. 


ROLES 


FUNCTIONS 


Acquisition  Manager 
Pro|act  Administrator 
Project  Manager 
Project  Leader 
System  Analyst 
S/W  Analyst 
Programmer 
S/W  Teat  Engineer 
S/W  Integrator 
S/W  Performance  Tester 
System  Integrator/Tester 
V&V  Personnel 
QA  Representative 
CM  Personnel 
PDSS  Personnel 
Training  Personnel 
MCCR  User 

SLCSE  Installation  Personnel 
Secretarial  Personnel 


VNOQRW 

AVNOQRW 

BKVNOPQRW 

KVNOPQRW 

CDFKNOPQRUW 

CDEFQKNOPQRVW 

DEFGNOPQRUW 

CDEFHLNOPQRW 

HLNOPQRW 

CDEFQHLNOPQRVW 

HLNOPQRW 

JNOPQRW 

INOPQRSW 

FKNOQRSW 

MNOPQSW 

ABKNOQRW 

KMNOQRW 

NOPQRSTW 

VNOQRW 


A.  Proi«el  Planning 

B.  Pro)tet  Contraf 

C.  Raquiramanta  Spacllleatlens 
and  Anafyala 

D.  Daaign  Spacifleatlon  and  Anaiyala 

E.  8/W  Prototyping  and  Modaling 

P.  Rauaabillty 

Q.  Program  Qanaratfon  Tooting 

H.  Intogratlon  Toot 

I.  QA 

4.  Vorlficatlon  and  Validation 

K.  Configuration  Managomont 

L.  8/W  H/W  Intogratlon 


M.  Poat'Doploymont  8/W  8upport 

N.  Communication 

O.  Doeumont  Qonaratlon 

P.  Data  Collootlon  Porformaneo 
Moaauromont 

O.  Help 

R.  Training 
8.  Tranaltlon 

T.  Tailoring 

U.  KnewtkJga  Englnoorlng 

V.  Admlnlatratlon 

W.  PR/ECR  Raporting 


Figure  3-1.  SLCSE  User  Roleb. 


Supports  instantiation  of  new  environments*  The  purpose  of  the  SLCSE  is  not  to 
create  a  single  Environment ,  but  to  provide  a  means  for  creating  environments  to  support 
the  unique  needs  of  each  individual  software  development  project.  This  means  that  a 
manager  should  be  able  to  sit  down  and  interactively  '•.t:.  a  new  environment,  in  a 
matter  of  hours  or  davs,  no*-  weeks  or  .^nths .  This  requirement  implies  that  the  methods 
employed  must  be  very  straightforward  -  almost  like  a  cookbook  -  and  that  no  special 
knowledge  should  be  required  of  the  creator,  other  than  that  already  required  to 
exercise  a  SLCSE  environment. 

Supports  distributed,  interprocess  control  and  communications.  Many  of  the  SLCSE 
tools  will  be  standalone,  executable  images.  The  SLCSE  must  be  abTe  to  “fire  off"  these 
tools  from  the  SLCSE  image.  This  requires  some  sort  of  interprocess  control  mechanism. 

In  addition,  interprocess  communication  facilities  are  needed  to  support  the 
distributed  nature  of  SLCSE  environments  {operating  either  on  a  host  computer  or  any 
number  of  networked  workstations)  and  "no-wait"  requests.  "No-wait"  requests  are 
generally  those  that  will  take  a  long  time  to  satisfy  -  like  a  complicated  database 
query  -  prompting  a  user  to  indicate:  *'I  want  this  request  done,  but  I  don't  want  to 
wait  for  the  results." 

Supports  embedded  methods.  A  life  cycle  model  like  DoD-STD-2167  specifies  what 
data  and  products  are  to  be  derived  from  a  software  development  process.  On  the  other 
hand,  a  software  development  methodology,  and  the  individual  methods  that  support  that 
methodology,  specifies  how  these  data  and  products  are  to  be  produced.  Standard  methods 
are  represented  in  a  SLCSE  environment  by  the  capabilities  of  the  tools  that  make  up  the 
environment , 

Additional  methods  may  be  needed,  however,  to  govern  the  day-to-day  operation  of 
an  environment.  For  example,  there  should  be  restrictions  on  access  to  tools  and  there 
should  be  rules  about  the  consequences  of  certain  user  actions  or  sequences  of  actions. 

Provides  a  tool  access  mechanism.  Tools  that  are  indirectly  coupled  to  the  SLCSE 
may  require  the  ^ior  specif icationof  runtime  information;  for  example,  the  name  of  a 
file.  The  SLCSE  must  provide  a  means  of  collecting  these  execution  parameters,  in  the 
form  of  a  tool  access  mechanism  for  each  SLCSE  tool  (as  required). 

Provides  information  access  mechanisms.  Information  access  needs  will  include 
file  access,  an  ad-hoc  query  capability  and  a  database  access  mechanism.  This  latter 
capability  is  required  by  indirectly  coupled  tools,  which  have  no  knowledge  of  external 
database  structures  and  so  must  make  use  of  import/export  mechanisms.  These  mechanisms 
will  be  used  to  pull  information  out  of  the  SLCSE  in  the  form  of  a  file  that  can  be  read 
by  the  tool  (or  vice  versa). 

Provides  four  kinds  of  input  utilities.  Utilities  must  be  provided  to  assist  tool 
builders  in  conforming  to  and  making  ef fTcient  use  of  the  SLCSE  user  interface. 
Specifically,  utilities  will  be  provided  for  Menu  Input,  Forms  Input,  Matrix  Input  and 
Script -Dr iven  input.  Menu  Input  will  support  the  selection  of  menu  options;  Forms  Input 
will  support  data  entry  via  f ill-in-the-blank  forms;  Matrix  Input  will  support  a  very 
simple  spreadsheet-like  data  entry  capability;  Script-Driven  Input  will  support 
"dialogue"  interactions  requiring  the  data  of  textual  information  -  like  the  sections 
and  paragraphs  of  a  document,  for  example. 

Provides  four  kinds  of  output  utilities.  Utilities  must  also  be  provided  for 
Display  Output,  Message  Output,  Graphics  Output  and  Print  Output.  Display  Output  will 
support  "painting"  a  window  with  appropriate  information  displayed  within  its  borders; 
Message  Output  will  support  presentation  of  prompt,  comment  and  error  messages;  Graphics 
Output  will  support  turning  raw  data  into  simple  scatter  and  histogram  plots;  Print 
Output  will  support  the  generation  of  hardcopy  listings  with  security  classification 
markings . 

Incorporates  help  and  training  facilities.  The  SLCSE  framework  will  support  two 
levels  on-line  help  (brief  an^  detailed)  and  an  on-line  training  facility. 

3.2  Database  Requirements 


Supports  use  of  a  Britton-Lee  lPM-500  Database  Machine.  To  help  alleviate 
anticipated  database  peFFormance  probTemsT  the  SLCSE  must  be  configured  to  run  with  a 
Britton-Lee  IDM-500  Database  Machine. 


Supports  PoD-STD-2l67«  although  not  precluding  other  life  cycle  models.  The  U.S. 
military  has  In  recent  years  standardized  on  one  particular  life  cycle  model: 
DoD-STD-2167 .  The  SLCSE  is  geared  toward  the  support  of  th^ s  model,  but  will  also 
support  other  models. 


Supports  the  description  of  an  Entity-Relationship  (ER)  database  model.  One  way 
to  reduce  the  complexity  of  traditional  database  models  is  to  describe  them  in  terms  of 
entities  and  relationships  like  the  example  shown  in  Figure  3-2.  ER  models,  because 
they  are  more  English-like,  are  much  more  natural  and  easier  to  comprehend.  The  SLCSE 
must  be  able  to  accept  database  descriptions  -  the  schema  -  in  terms  of  an  ER  model. 
Additionally,  the  syntax  employed  must  be  one  familiar  to  database  model  developers  and 
must  provide  a  means  for  decomposing  database  structures  into  smaller  structures  (i.e. 
subschemas ) . 
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Figure  3-2»  Sample  Entity  Relationship  (ER)  Model. 


Supports  ER-type  database  queries .  The  SLCSE  must  support  both  direct  and 
indirect  ER-type  database  queries.  Application  tools  that  ‘'know"  about  the  ER  structure 
will  make  direct  database  queries?  other  applications  will  depend  upon  interface 
mechanisms  that  make  use  of  a  standard  query  language.  Both  static  (precompiled)  and 
dynamic  (on-the-fly)  queries  must  be  supported. 

Supports  version  management.  The  database  is  not  a  fixed  structure:  it  has  a 
"timeline"  sense  as  well.  The  SLCSE  must  support  control  and  management  of  different 
versions  of  database  items. 

Supports  control  of  database  access.  Users  must  not  be  allowed  to  change  the  same 
database  element  at  the  same  time.  The  SLCSE  must  support  a  system  of  database 
locking/unlocking  mechanisms  to  prevent  such  an  occurrence. 

Additionally,  there  must  be  support  for  data  distribution.  Mth'^ugh  there  will  be 
on^y  one  master  database,  hosted  by  a  single  computer,  the  SLCSE  must  be  able  to  deal 
with  a  network  of  computers  running  the  same  environment,  but  either  requesting 
information  from  the  master  database  or  downloading/uploading  portions  of  the  master 
database . 

Supports  database  archiving.  It  periodically  becomes  necessary  to  archive 
portions  of  a  database.  The  SLCSE  must  support  this  function  in  an  efficient  manner. 

3.3  Toolset  Requirenents 

Supports  integration  of  30  tools  in  ten  tool  cat^^gories.  SLCSE  3.0  will  support 
commmer c i a 1  too 1 s ,  Government-furnished  (GFEI  tools  and  tools  especially  built  for 
integration  into  the  SLCSE.  The  tools  are  listed  in  Figures  3-3  and  3-4  in  terms  of 
ten  tool  categories.  Briefly,  the  tools  are  as  follows: 


Figure  3-3.  SLCSE  Toolset. 


General  tools.  This  category  includes  a  text  editor,  command  language  editor  and 
mail  facility,  as  well  as  a  document  formatter. 

Verification  tools.  In  the  verification  tools  category,  a  tracing  capability  will 
be  provided  by  the  Automated  Life  Cycle  Impact  Analysis  (ALICIA)  system  and  quality 
analysis  will  be  provided  by  the  Automated  Measurement  System  (AMS).  Other  capabilities 
will  be  provided  by  the  Ada  Test  and  Verification  System  (ATVS)  for  Ada?  J73  Automated 
Verification  System  (J73AVS)  for  JOVIAL?  RXVP80  for  FORTRAN?  and  Cobol  Automated 
Verification  System  (CAVS)  for  COBOL. 

Requirettents  analysis  tools.  All  capabilities  in  the  requirements  category  will 
be  provided  by  a  new  tool  to^e^uilt  for  the  SLCSE. 

Design  tools.  All  capabilities  in  the  design  category  will  be  provided  by  the 
Softw^e  l)eelgn  and  Documentation  Language  (SDDL)  tool . 

Coding  tools.  In  the  coding  category*  syntax-directed  editing  capabilities  will 
be  provided  by  DEC ' s  Language  Sensitive  Editor  (LSE).  Other  DEC  tools  will  provide 
compiling,  assembling,  linking  and  debugging  support,  except  that  the  JOVIAL  compiler 
will  be  provided  by  Proprietary  Software  Systems  (PSS).  Executable  assertion 
translation  for  Ada  will  be  provided  by  ATVS?  Executable  translation  for  JOVIAL  will  be 
provided  by  J73AVS. 
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Figure  3-4.  SLCSE  Toolset  (Continued). 


Testing  tools.  A  Test  Manager  and  Test  Data/Results  Manager  tool  will  be  built 
for  the  SLCSE.  Other  capabilities  will  be  provided  by  ATVS,  J73AVS,  RXVP80  and  CAVS. 

Configuration  manageisent  tools.  A  Software  Configuration  Manager  and 

Documentation  Manager  will  be  built  for  the  SLCSE.  Change  impact  analysis  capabilities 
will  be  provided  by  ALICIA. 

Project  Management  tools.  All  project  management  capabilities  will  be  provided  by 
the  Automated” Project  Management  System  (APMS). 

Environnent  manaqenent  tools.  All  environment  management  capabilities  will  be 
provided  by  new  tools  built  for  the  SLCSE. 

Prototyping  tools.  Prototyping  and  special  purpose  tools  will  be  included  in  this 
category"]  including  a  window  prototyper  (WINNIE). 

4  SLCSE  MAJOR  DESIGN  CONCEPTS 

4.1  User  Interface  Design  Concepts 

Data  P’-iven  Interfaces.  The  SLCSE  user  interface  will  make  substantial  use  of  a 
sophisticated  window  management  package  (WINNIE)  am*  an  associated  table  driver 
mechanism  (MOO).  This  existing  software  will  make  it  much  easier  to  design  and  tailor 
an  easy-to-use  interface.  The  WINNIE  and  MOO  packages  support  a  rich  repertoire  of 
windowing  operations  and  do  so  in  the  form  of  input  data,  not  code.  See  Figure  4-1. 
This  means  that  the  SLCSE  design  process  can  easily  include  a  number  of  successively 
improved  user  interface  prototypes.  This  is  important  because  experience  has  shown 
that  easy-to-use  is  a  subjective  sort  of  requirement;  users  need  some  framework  to  work 
with  in  order  to  provide  feedback  on  user-friendliness. 
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I  UIMIIK  Fll«  for  SLC8B  CoMMtd  iMcutlva 

UlMDOU  5  IS  kJ  It  S 
UlVlSIiU 
nUMB  VITHOUr  10 
fRAMB  VIOlO  •BOLD* 

VBRTiaO.  SiaOLL 

Tin  1  4  *  HIGH  mORlTY  TOOLS  *  ‘UVBBSB* 
fORM  1 

ACCUS  BY  Mum  WITH  BBTOU 

HBLf  151  2  *  M«lp  lafocMClMi  will  «pp«AC 

HBLD  1  3  5  24  •fLAUI''  •BOIA  ttVBSB*  ttOTICT 
DBFAULT  *FroJ«ct  lUMgpMic  (AfNS)  ■ 

LABSL  3  1  •  1.  •  •FLAIH*  -BOLD  BBVBB5B- 

FIBLD  2  4  S  24  ■PUlkl-  *4010  BBVBBSf  ROtBCT 
OBPAULT  *Spr««4«tM«C  (FCAliC)  * 

LABBL  4  1*2.  *  *PUIlf*  *BOLD  BBVBBSB* 

PIBLO  3  S  5  24  *PU1H*  "BOLD  RBVBBSB-  PSOTBCT 
OBPAIILT  •tmxt  BAiCoc  <BOT)  * 

LABBL  5  1*1.  •  *PUIN*  *aOLD  BBVBBSB* 


I  HOO  Fll«  for  SLCS£  Coasond  executive . 

IP  VIMDOU  •  1  AND  FIELD  -  1  THEN  UPON 
CBBT-VU  99  146.  00  TO  4. 

1  Window  S  1*  Project  Naneger  Toole  Window. 

IP  VIHOOW  •  5  AND  FIELD  -  1  2  3  4  S  THEN  UPON  TAB- 
MV  197,  VIS  144,  BETURN;  CRET-INV  197.  ADV  144. 

IF  WINDOW  -  S  AND  FIELD  -  6  THEN  UPON  TAB-IHV  197  , 
VIS  144.  BBTUtN;  CEET<»AOV  30.  INV  197.  VIS  3 

I  Window  4  le  Project  tUneper  Toole  Window. 

IF  WINDOW  •  4  AND  FIELD  -  1  2  3  4  THEN  UPON  TAB- 
INV  197,  VIS  164,  EETUEN:  CRET-INV  197,  ADV  144 

IF  WINDOW  -  4  AND  FIELD  -  5  THEN  UPON  TAB-INV  197 
VU  144,  BETURN;  CRTT-ADV  30,  IHV  197,  VIS  3. 

1  UlndM  14  te  the  exit  conflraetlon  window. 

IF  WINDOW  -  14  and  FIELD  -  1  THEN  UPON  CRET- 
CASB  OF  (TEST) . 

CASE  (*Y*).  CODE  EXIT. 

CASE  ELSE,  RETURN . 

END  CASE. 


Explanation  of  first  block:  Window  #5  is 
invisible;  has  a  bolded  frame;  is  verti¬ 
cally  scrollable  and  has  the  words  HIGH 
PRIORITY  TOOLS  at  the  top  in  reverse  video. 
There  is  one  form  in  the  window  and  the 
associated  help  window  is  #151. 


Explanation  of  first  block:  If  control 
is  at  window  #1  and  field  #1  (i.e.  the 
Ist  input  field),  then  if  the  user  hits 
a  carriage  return,  visibilize  window 
#99  and  #166  and  turn  control  over  to 
window  #4. 


Figure  4-1.  WINNIE/MOO  Data  Excerpts. 


Environment  Instantiation  Methodology .  Environments,  like  applications  software, 
have  a  life  ^ycle.  For  SLCSE  environm^ts,  this  life  cycle  is  illustrated  by  the 
diagrams  in  Figures  4-2  through  4-5. 

First,  the  SLCSE  must  be  installed.  TVj©  SLCSE  will  be  delivered  to  a  new 
installation  site  with  a  single  working  environment  -  for  installation  purposes  -  and 
several  Environment  Specifications  PaeVages  -  for  use  as  default  mechanisms  in 
subsequent  instantiation  activities.  SLCSE  Installation  Personnel  will  decide  whether 
or  not  to  create  additional  Environment  Specifications  Packages  beyond  those  supplied 
for  small,  medium  and  large  projects,  and  will  instantiate  the  first  environment  for 
actual  project  use. 

Creating  an  Environment  Specifications  Package  (ESP)  or  a  Project  Environment  (PE) 
involves  specifying  and/or  entering  data  that  describes  all  the  characteristics  of  an 
environment:  the  operating  environment  (hardware/sof tware  configuration),  the  users,  the 
embedded  methods  that  will  govern  the  environment  and  miscellaneous  information  (help, 
etcetera) .  ESPs  reduce  the  amount  of  work  involved  in  instantiating  a  PE,  because  they 
provide  reasonable  defaults  for  most  data  items. 

After  a  PE  has  been  instantiated,  it  may  then  be  put  to  use  supporting  software 
development  activities.  It  is  important  to  recognize  that  the  SLCSE  Database  is  really 
two  databases: 

(1)  A  Project  Database  that  is  a  storehouse  for  information  on  the  software 
development  project 

(2)  An  Infrastructure  Database  that  keeps  track  of  parameters  and  options  associated 
with  the  Environment  framework 

Some  users,  of  course,  will  deal  almost  exclusively  with  ordinary  data  files.  The 
Programmer  role,  for  example,  will  involve  the  ad-hoc  creation  of  source  code  files. 
All  such  files  will  be  known  to  the  Infrastructure  Database  -'because  they  must  show  up 
as  valid  menu  options  -  but  these  files  will  be  unknown  to  the  Project  Database  until 
they  are  officially  "imported”  into  the  appropriate  data  structures  of  that  database. 

There  will  eventually  come  a  time  when  a  PE/ESP  must  be  updated.  This  will 
involve  the  same  sorts  of  activities  as  in  instantiation  except  that  users  must  be 
locked  out  of  the  PE/ESP  while  the  update  is  effected. 


Figure  4-3.  Create  Specs/Environment  Thread 
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Figure  4-6.  Scheduler  Mechanism. 


Scheduler  Mechanism.  The  Scheduler  Mechanism  has  been  designed  in  two  parts:  a 
Tooler  and  a  Message  Handler.  Refer  to  Figure  4-6. 

Each  StX^SE  process,  during  its  initialization,  will  spawn  a  Tooler  subprocess  that 
will  communicate  with  the  main  process  via  mailbox  services.  The  Tooler  subprocess  will 
hibernate  until  sent  a  command  from  the  main  process.  It  will  execute  this  command, 
taking  temporary  control  of  the  screen.  This  is  the  manner  in  which  standalone, 
executable  images  will  be  controlled  from  SLCSE  processes. 

Also,  each  computer  in  the  environment  will  have  a  single,  detached  Message 
Handler  process.  All  SLCSE  processes  will  establish  communication  with  this  Message 
Handler,  which  will  take  care  of  “no  wait"  requests  via  a  SLCSE  batch  queue  and  will 
handle  the  distributed  aspects  of  an  environment  via  network  utilities. 


Figure  4-7.  Methods  Mechanism. 


Methods  Mechanism.  The  Methods  Mechanism  has  been  designed  in  three  parts:  an 
Activity  Monitor,  a  File  Handler  and  a  Knowledge  Base.  Refer  to  Figure  4-7. 

The  Activity  Monitor  keeps  track  of  user  requests  and  sequences  of  user  requests, 
deciding  when  to  invoke  the  File  Handler  and  Knowledge  Base  and  when  to  update 
information  about  the  current  situation  (i.e.  the  facts).  The  File  Handler  uses 
operating  system  utilities  to  prevent  unauthorized  access  to  files.  The  Knowledge  Base 
-  implemented  in  Prolog  -  will  store  and  enable  assessment  of  procedural  type  rules 
governing  an  environment.  This  will  be  the  mechanism  whereby  a  project  manager  can  both 
encourage  and  enforce  adherence  to  project  specific  methods. 


Figure  4-8.  Schema  Language  Compiler. 


4.2  Database  Design  Concepts 

SMARTSTAR/0MNIB^SE»  There  is  only  one  commercial  database  management  system  that 
uses  the  BrI ttorT  O'a^base  Machine:  OMNiBASE.  Fortunately  OMNlBASE  has  a  looXalike  - 
SMARTSTAR  -  that  can  make  use  of  ordinary  disk  units.  The  SLCSE  will  be  developed  using 
SMARTSTAR/  but  will  be  installed  at  the  RADC  Computer  Facility  using  OMNIBASE. 

Schema  Generator.  The  SLCSE  Database  Schemas  and  Subschemas  will  be  developed  in 
the  form  of  Entity-Relationship  (ER)  models  which  will  be  expressed  in  an  Ada-like 
language.  This  language  will  be  compiled  as  illustrated  in  Figure  4-8. 

The  Lexer/Parser  will  transform  the  input  text  into  tokens,  parsing  them  into 
internal  tables  of  information.  In  the  process,  it  will  report  syntax  errors  and 
produce  a  cross-reference  listing  of  entities,  attributes  and  relationships,  showing 
where  they  are  defined  and  used. 

The  Optimizer  will  select  attributes  to  be  indexed  and  will  select  representations 
of  relationships,  so  as  to  optimize  runtime  access  speeds. 

The  Generator  will  read  the  tables  produced  by  the  Lexer/Parser  or  the  Optimizer 
and  generate  the  final  outputs  of  the  compiler: 

(1)  Database  Creation  Code,  a  file  of  Structured  Query  Language  (SQL)  statements  that 
will  create  and  initialize  an  empty  database  that  matches  ihe  input  8chema(s) 

(2)  Schema  Definition  Tables,  Ada  packages  that  will  be  used  for  type  checking  by 
SLCSE  applications 
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Figure  4-9»  Database  Interfaces. 


ER  Interface.  Ultimately,  a  SLCSE  application  will  want  to  store  and  retrieve 
informatToTi  from  the  SMARTSTAR/OMNIBASE  Database,  still  making  use  of  the  ER  model 
forms.  Using  the  Schema  Definition  Tables  produced  by  the  Schema  Language  Compiler,  a 
SLCSE  application  will  communicate  an  ER-type  request  to  the  ER  Interface,  which  will  in 
turn  communicate  the  request  to  the  underlying  database,  SMARTSTAR/OMNIBASE .  See  Figure 
4-9. 


4.3  Toolset  Design  Concepts 

Tool  Integration  Guidelines.  Guidelines  for  coupling  tools  with  the  SLCSE  will  be 
published  as  part  of  the  Software  Programmer’s  Manual. 

Directly  coupled  tools  will  conform  to  user  interface  standards  set  forth  in  the 
guidelines  and  will  know  about  and  make  direct  use  of  the  SLCSE  Project  Database. 
Directly  coupled  tools,  then,  will  look  and  act  like  extensions  to  the  SLCSE  framework. 

Indirectly  coupled  tools  will  maintain  their  original  user  interface  and  will 
neither  know  about  nor  make  direct  use  of  the  SLCSE  Project  Database.  This  means  that 
there  will  be  a  non-SLCSE  look  to  such  tools  and  that  interface  mechanisms  may  have  to 
be  designed  to  preprocess  or  postprocess  data  for  their  internal,  non-SLCSE  databases. 

5  SLCSE  IMPLEMENTATION  AND  RESULTS  TO  DATE 

5.1  The  Eight  Incremental  Builds 

As  previously  mentioned,  the  SLCSE  is  being  de  eloped  in  a  series  of  eight 
incremental  builds  spanning  a  twenty-four  month  period.  Refer  to  Figure  5-1.  Builds  1 
through  7  are  three  months  in  duration  (a  quarter  system).  The  last  developmental 
quarter  will  be  a  one  month  build  (Build  8)  followed  by  two  months  of  installation 
activities.  An  incremental  build  approach  was  chosen  to  enable  early  prototyping  of 
critical  functions  and  to  provide  an  "early  warning'  mechanism  for  an  ambitious 
development  schedule.  New  capabilities  are  demonstrated  at  the  close  of  each  quarter: 
if  the  required  capabilities  cannot  be  demonstrated,  the  project  is  behind  schedulel 
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Figure  5-1.  SLCSE  Builds  and  Major  Milestones. 


Build  1  -  Concept  Validation  -  will  demonstrate  the  “look”  and  "feel"  of  the  User 
Interface  and  establish  specifications  for  the  various  Database  Interfaces.  Build  2  - 
Framework  -  will  prove  the  viability  of  the  Scheduler  mechanism  and  will  demonstrate 
limited  Database  functionality.  Build  3  -  Toolset  1  Integration  -  will  integrate 
standard  operating  system  tools  into  the  SLCSE,  will  demonstrate  full  Database 
functionality  and  will  introduce  a  Tool  Access  mechanism  (for  indirectly  coupled  tools'. 
Build  4  -  Database  Optimization  -  will  complete  the  SLCSE  Database  Subsystem  and 
associated  database  management  utilities,  will  demonstrate  a  Database  Access  mechanism 
(also  for  indirectly  coupled  tools)  and  will  integrate  a  prototype  Automated  Project 
Management  System  (APMS).  Build  5  -  Method  Support  «  will  implement  a  SLCSE  Rule  Base 
supporting  methodology-based  advice  and  monitoring  features  and  will  demonstrate  the 
capability  to  instantiate  a  new  environment.  Build  6  -  Toolset  2  Integration  -  will 
integrate  all  Environment  Management  tools  and  at  least  one  tool  from  each  of  the  other 
tool  categories.  Build  7  -  Toolset  3  Integration  -  will  complete  the  SLCSE  User 
Interface  and  will  integrate  the  complete  SLCSE  Toolkit,  including  tools  being  built 
under  other  Air-Force-sponsored  contracts.  Build  8  -  Shakedown  -  will  install  help  and 
training  facilities  for  the  SLCSE  and  will  include  production  testing  of  the  system. 

The  Preliminary  Design  Review  (PDR)  and  Critical  Design  Review  (CDR)  will  be  held 
at  six  and  twelve  months  into  the  project,  respectively.  However,  because  of  the 
incremental  builds,  both  of  these  reviews  will  involve  preliminary  designs,  detailed 
designs  and  actual  code. 

Three  versions  of  the  SLCSE  will  be  installed  at  the  Rome  Air  Development  Center 
computer  facility.  Version  1.0,  at  ten  months  into  the  project,  will  be  geared  toward 
the  support  of  coding  functions.  Version  2.0,  at  nineteen  months  into  the  project,  will 
support  coding,  project  management  and  SLCSE  installation  functions  and  will  demonstrate 
some  functionality  across  the  life  cycle  for  at  least  one  of  the  supported  programming 
languages.  Version  3.0,  at  twenty-three  months  into  the  project,  will  support  the 
complete  software  development  life  cycle  for  Ada,  JOVIAL,  FORTRAN  and  COBOL. 

5.2  Build  1  Results 

Build  1  was  completed  in  eirly  December,  1986,  as  scheduled. 

A  SLCSE  user  interface  was  designed  arid  demonstrated.  Referring  to  the  sample 
display  in  Figure  5-2,  the  User  Interface  makes  full  use  of  advanced  windowing 
technologies.  The  current  process  (either  SLCSE  or  one  of  the  SLCSE  tools)  is  indicated 
at  the  top  of  the  screen,  along  with  the  current  user  role  (on  the  far  right)  and  the 
current  object  (on  the  far  left),  if  any  has  been  specified.  The  bottom  of  the  screen 
is  used  consistently  for  prompt,  error  and  comment  messages.  The  SLCSE  may  be  exercised 
in  either  Menu  Node  or  Keyword  Input  Mode.  Every  Menu  option  has  an  identical  Keyword 
option.  However,  in  Keyword  Input  M“'de,  the  user  only  has  to  enter  as  many  characters 
as  are  needed  to  uniquely  identify  the  option.  In  Menu  Mode,  command  buttons  appear 
underneath  the  top  line  with  the  following  meanings: 

OBJECTS  -  for  a  list  of  available  f iles/database  items 

TOOLS  -  for  a  list  of  available  software  development  tools 

PROCEDURES  -  for  a  list  of  available  software  development  procedures 

ADVICE  -  for  various  kinds  of  advice  on  software  tasks 

MODE  -  to  change  user  modes/parameters 

HELP  -  for  detailed  help  on  how  to  use  the  SLCSE 

EXIT  -  to  get  out  of  the  SLCSE 
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Figure  5-2‘  Sampl^i  SLCSE  Display. 


Windows  drop  down  from  the  command  button  line.  For  objects,  tools  and  procedures 
-  referred  to  collectively  as  components  -  the  windows  cascade  down  and  to  the  right  in 
three  tiers.  The  highest  level  menu  displays  the  components  commonly  used  on  a 
day-to-day  basis;  the  next  level  menu  displays  a  list  of  component  categories;  the 
lowest  level  menu  displays  a  catalog  of  all  components  available  to  the  user  in  a 
particular  component  category.  These  displays  are  tailored  for  each  user  role  so  that, 
for  example,  what  a  Programmer  sees  is  different  than  what  a  Project  Manager  sees. 
Additionally,  each  user  may  tailor  their  own  particular  displays  by  raising  components 
from  the  component  catalog  to  the  "commonly  used"  menu  or  lowering  components  from  the 
"commonly  used"  menu  to  the  component  catalog.  While  many  of  the  components  available 
to  the  user  are  under  database  control,  users  may  also  work  with  private,  non-controlled 
components.  These  may  be  created,  copied  and  deleted  by  bringing  up  a  special  menu  as 
shown  in  the  lower  righthand  corner  of  Figure  5-2. 

The  tailoring  capabilities  supported  by  the  SLCSE  User  Interface  will  go  a  long 
way  toward  fostering  user  acceptance  of  SLCSE  environn.ents . 

6  SLCSB  TESTING  &  VERIFICATION 

Development  of  the  SLCSE  will  advance  the  state-of-the-art  in  software  tool 
integration  technology  and  software  development  life  cycle  support  by  undertaking  the 
design  and  implementation  of  highly  sophisticated  and  complex  Man-Machine-Interface  and 
database  components  as  well  as  the  difficult  integration  of  new  software  development 
tools  with  existing  off-the-shelf  capabilities*  There  is  moderate  technical  risk  in 
developing  an  environment  such  as  the  SLCSE,  not  only  due  to  the  required  functionality, 
but  also  due  to  performance  concerns;  a  sluggish  environment,  no  matter  how  effective 
and  easy-to-use,  will  not  be  accepted  by  users.  With  this  element  of  risk,  testing  and 
verification  activities  to  be  performed  by  both  the  contractor  and  the  Government  are 
critical . 

Verification  is  the  iterati^’e  process  of  deteri:iining  whether  the  developing 
product,  at  each  phase  of  the  life  cycle,  fulfills  the  requirements  esta'^  lushed  by  the 
previous  phase.  The  process  provides  a  level  of  assurance  that  serioui,  ’riors  do  not 
exist,  that  all  user  requirements  have  been  supported,  and  that  critica.  tunctions  of 
the  final  product  will  not  fail  during  operational  use.  The  incremental  build  approach 
for  developing  SLCSE  will  provide  a  series  of  interim  products  which  will  give  both  the 
contractor  and  the  Government  several  test  and  verification  <;pportunitie8  for 
evaluating  the  adequacy  of  SLCSE  design  concepts,  implemented  functionality,  and 
performance.  These  opportunities  also  make  possible  timely  corrective  actions,  as 
necessary.  Each  of  the  eight  SLCSE  builds  will  be  reviewed  by  the  Government.  Versions 
1.0  and  2.0  of  SLCSE,  which  will  consist  of  "threads"  or  "vertical  slices"  of 
functionality,  will  be  formally  delivered  to  the  Government  and  acceptance-tested.  The 
final  delivery,  SLCSE  Version  3.0,  will  be  tested  in  accordance  with  a 
Government-approved  Software  Test  Plan,  Software  Test  Description,  and  software  Test 
Procedures,  each  of  which  will  be  prepared  in  accordance  with  DoD-STD-2167. 

Proof  of  SLCSE* B  sufficient  functionality  and  system  responsiveness  will  be 
initially  demonstrated  by  its  ability  to  support  itself;  as  development  of  SLCSE 
proceeds,  available  components  of  SLCSE  will  be  used  by  the  contractor  to  implement 
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subsequent  SLCSE  components.  As  a  result,  upon,  delivery  of  SLCSE  Version  3.0,  a 
significant  subset  of  SLCSE  will  exist  and  be  supportable  within  itself. 

7  SLCSE  FUTURE  DIRECTIOHS 

Beyond  the  scheduled  SLCSE  3.0  delivery,  the  SLCSE  will  continue  to  evolve.  The 
SLCSE  toolset  will  be  considerably  expanded  and  the  supporting  technologies,  especially 
for  the  Project  Database,  will  continue  to  be  developed.  The  SLCSE  will  also  provide  an 
important  R&D  base  for  state-of-the-art  advances  in  life  cycle  software  development 
technology.  The  key  to  future  advances  and  the  potential  for  realization  of  advanced 
operational  life  cycle  software  engineering  capabilities  lies  with  the  project  database. 
By  providing  for  the  efficient  storage,  management,  and  retrieval  of  all  data  generated 
throughout  the  life  cycle,  the  database  makes  possible  the  development  of  several 
high-payoff  capabilities.  Such  technologies  as  life  cycle  impact  analysis  and 
assessment,  automated  documentation  generation  and  data  collection  for  quality  and 
productivity  measurement  will  be  the  focus  of  much  of  the  future  research. 

Impact  analysis.  The  process  of  impact  analysis  and  assessnient  is  required 
whenever  a  change  is  contemplated  to  an  MCCR  system.  Hi  s  tor  i  ca  1 1  s' ,  the  extent  of 
changes  to  an  initial  MCCR  system  has  ranged  from  adding  minor  requirements  to  changing 
the  entire  system  concept.  Changes  can  come  about  because  of  new  or  updated 
requirements,  unexpected  results,  error  detection/correction,  inter-  and  intra-aystem 
interface  anomalies,  and  performance  characteristics  that  are  not  responsive  to 
mission-derived  specifications.  Such  changes  can  significantly  contribute  to  cost  and 
schedule  overruns.  Effective  change  impact  analysis  during  development  and 
post-deployment  support  can  help  overcome  these  difficulties  by  providing  support  for 
(1)  adapting  to  changing  requirements,  (2)  evaluating  proposed  design  changes  or 
alternative  designs,  (3)  correcting  errors,  and  (4)  enhancing  MCCR  systems.  Automated 
impact  analysis  and  assessment  will  improve  the  resulting  quality  of  MCCR  software  by 
reflecting  changes  more  completely  and  reliably,  without  adding  undesirable  side 
effects.  While  SLCSE  3.0  will  have  a  limited  impact  analysis  capability  supported  by  a 
small  set  of  determir.iotic  algorithms,  a  more  advanced  capability  utilizing  heuristic 
and  stochastic  algorithms  is  planned. 

Automated  documentation.  An  MCCR  system  development,  requires  the  generation  of 
documents  which  describe  the  software  product  and  which  conform  to  military  standards 
such  as  DoD-STD-2167 .  Documentation  accounts  for  40%  of  total  software  development 
costs,  but  the  lead  time  required  for  documentation  updates  hampers  the  timely 
transition  of  a  system  update  to  the  field.  Thus,  it  is  important  that  advanced 
environments  such  as  SLCSE  provide  documentation  support.  The  SLCSE  project  database 
will  be  capable  of  storing  all  pertinent  information  generated  during  the  software  life 
cycle.  Documentation  generators  are  planned  for  each  of  the  DoD-STD-2167  Data  Item 
Descriptions  (DiDs).  These  will  be  available  to  extract  information  from  the  project 
database  (user-generated  text,  graphics,  tool-generated  tables,  etc.)  and  produce  or 
update  the  relevant  documents. 

Quality  and  productivity  measures.  The  measurement  and  assessment  of  product 
quality  and  deveTopment  productivity  is  becoming  an  important  concept  in  the  control  of 
a  software  development  project.  The  current  state-of-the-art  is  limited  to  the 
existence  of  a  few  tools  which  provide  both  the  data  collection  and 
measurement/assessment  functions.  The  data  is  normally  collected,  if  not  manually, 
through  the  use  of  static  analyzers  and  post-processors  which  filter  appropriate  data 
from  an  individual  software  tool's  data  files.  Future  research  will  be  focused  on  the 
automated  collection  of  pertinent  data,  throughout  the  entire  software  life  cycle,  in  a 
manner  which  is  as  transparent  as  possible  to  the  users  of  environment  tools.  This 
approach  not  only  supports  the  complete  collection  of  correct  and  consistent  data,  but 
also  relieves  measurement  and  assessment  tools  of  the  responsibility  and  burden 
resulting  from  the  storage,  management,  and  retrieval  of  the  data. 

8  CONCLUDING  RS4ARKS 

The  SLCSE  is  but  one  project  in  a  long  line  of  successful  (and  unsuccessful) 
efforts  aimed  at  establishing  software  development  environments.  It  is,  however,  unique 
in  many  respects: 

Distributed .  The  SLCSE  environment  operates  from  a  host  computer  and  any  number 
of  workstations . 

Multi- lingual .  The  SLCSE  will  support  software  development  in  any  (or  all)  of  four 
languages  -  JOVIAL,  Ada,  FORTRAN  and  COBOL. 

Embedded  methods.  The  SLCSE  inclu'^es  a  spectrum  of  capabilities  involving 
methods ,  everything  from  advice  on  how  to  go  about  doing  a  task  to  monitoring  user 
actions  to  ensure  adherence  to  particular  project  rules. 

Detailed,  high  performance  database.  The  SLCSE  Project  Database  includes  the 
complete  information  content  of  all  of  the  project  documents  described  in 
DoD-STD-2167  data  item  descriptions  (DIDs),  implemented  on  a  high  performance 
IDM-500  Database  Machine. 

ER  front  end.  Access  to  SLCSE  data  is  via  an  Engl ish- like ,  easy-to-understand 
model,  the  Entity-Relationship  (ER)  model.  This  makes  use  and  maintenance  of  the 
detailed  database  more  straight  forward. 


Evolving  toolset.  The  SLCSE  has  been  designed  to  easily  accommodate  new  and 
existing  tools.  This  makes  it  a  perfect  starting  point  for  developing  unique  MCCR 
environments . 

Life  cycle  software  development  environments  are  one  of  the  most  important  areas 
of  research  in  software  engineering  today.  They  are  a  ''precursor"  technology,  a 
technology  that  must  come  to  fruition  if  certain  other  technologies  -  like  automated 
simulation  synthesis  -  are  to  succeed.  Unfortunately,  even  though  the  goal  is  clear, 
the  path  toward  achieving  that  goal  is  treacherous,  littered  here  and  there  with 
abandoned  sheila  and  crumbling  monoliths.  Those  who  have  succeeded  in  some  measure  are 
those  who  have  left  the  path  altogether  to  create  environments  with  limited  scope  or 
functionality. 

SLCSE  is  not  among  these  efforts.  Its  goal  of  a  mul t i - 1 ingua 1 ,  integrated 
software  development  environment  across  the  complete  life  cycle  is  as  ambitious,  if  not 
more  so,  than  those  of  previous  efforts:  Yet  SLCSE  is  different.  It  preserves  the 
goal,  but  chooses  to  achieve  that  goal  in  small  increments,  finding  solutions  to  the 
tough  problems  first  and  maintaining  an  unprecedented  flexibility  in  design. 

The  SLCSE  project  is  like  the  successful  Design  Engineer  who,  given  a  task,  would 
immediately  set  down  the  first  thoughts  that  came  to  him  and  present  them  to  a 
colleague.  His  colleague  would,  of  course,  tear  this  ill-conceived  concept  to  shreds. 
The  Design  Engineer  would  carefully  evaluate  all  this  criticism  and  shortly  come  up  with 
a  revised  concept,  which  he  would  present  to  a  different  colleague  for  review.  This 
iterative  process  would  continue  until  the  concept  was  completely  thought  out.  This 
Design  Engineer  was  given  only  the  most  difficult  assignments  and  always  succeeded. 
This  person  actually  exists  and  was  described  in  recent  literature  to  illustrate  the 
winds  of  change  that  are  sweeping  the  engineering  disciplines. 

The  iterative  design  technique  -  what  we  generally  refer  to  as  incremental  builds 
and  prototyping  -  is  an  invaluable  aid  for  projects  on  the  forefront  of  technology. 
SLCSE,  with  its  eight  incremental  builds  and  intermediate  prototypes,  has  fully  embraced 
this  new  approach  and,  after  a  successful  first  build,  has  a  foot  solidly  on  the 
goal-directed  path.  Only  time  will  tell  if  the  footsteps  are  sure  enough,  or  the  stride 
long  enough,  to  take  us  into  a  new  age  of  software  innovation. 


DISCUSSION 


R.Guoit«  FR 

What  are  you  doing  about  the  problem  of  performance? 

Aulhor*s  Reply 

We  are  using  a  database  machine,  which  helps  a  little.  Also,  we  are  using  all  that  database  technology  has  to  offer  in 
terms  of  prefetching  and  catching  data  —  anticipating  what  the  user  will  need  next.  Finally,  every  major  component  of 
the  SLCSE  will  undergo  an  optimization  pass  to  ensure  the  production  code  is  as  efficient  as  possible. 


Question 

How  is  the  SLCSE  related  to  specific  MCCR  programs? 

Author’s  Reply 

The  Rome  Air  Development  Center  sponsor  is  tasked  with  developing  state-of-the-art  technologies,  which  are  then 
provided  to  operational  groups  with  the  Air  Force.  The  SLCSE  will  be  of  great  interest  to  those  groups  developing 
MCCR  software  as  soon  as  it  has  been  proven  production-worthy. 

M.Muenier,  FR 

Ada  is  one  of  the  languages  supported  by  the  SLCSE.  There  is  an  ongoing  effort  to  standardize  environment  to  support 
Ada,  namely  the  C  AIS.  What  is  your  position  on  this  point? 

Author’s  Reply 

We  are  very  familiar  with  the  work  on  CAIS  and  agree  with  the  basic  idea;  however,  we  feel  that  it  has  a  long  way  to  go 
before  it  will  be  of  use  to  applications  developers.  Current  implications  of  the  CAIS  are  a  subset  of  the  CAIS 
specification,  are  agonizingly  slow,  take  up  a  tremendous  amount  of  interna!  and  external  memory,  and  are  not  truly 
portable  (having  small  amounts  of  system-dependent  code). 

P.Siinons,  US 

Does  the  SLCSE  support  the  development  of  embedded  code? 

Author’s  Reply 

Embedded  code  very  often  requires  tools  such  as  target  simulators  and  cross-assemblers.  Such  capabilities  are  not  a 
part  of  the  basic  SLCSE  tool  set  but  could,  of  course,  be  added  in  the  future. 


34-l‘J 


G.Bouche«  GE 

Will  the  SLCSE  be  available  to  the  NATO  community?  If  so»  when? 

Author's  Reply 

Yes,  both  General  Research,  the  prime  contractor,  and  the  Rome  Air  Development  Center,  the  sponsor,  are  committed 
to  the  expeditious  transfer  of  this  technology. 


DJSchimsky,  US 

Do  you  think  that  the  lack  of  portability  of  the  tools  (e.g.,  VAXA^S)  is  a  handicap?  What  do  you  think  of  recent 
efforts  to  standardize  on  an  OS  called  POSIX? 

Author's  Reply 

A  great  number  of  military  installations  are  committed  to  VAXA^S,  so  we  think  that  the  SLCSE  has  wide 
applicability.  On  the  issue  of  standard  OSs,  we  have  heard  for  the  last  10  years  that  one  OS  or  another  would  become  a 
'‘standard,’*  but  we  have  yet  to  see  a  real  standard  emerge  due  to  the  vendors'  reluctance  to  support  such  a  move. 


M.Kayton,  US 

For  what  purpose  does  your  customer  intend  to  use  the  SLCSE  after  you  deliver  your  three  builds?  Your  paper  refers 

to  development  of  MCCR  software,  and  you  addressed  the  development  of  tools. 

Author's  Reply 

( 1 )  First,  we  must  clarify  two  points.  The  first  point  is  that  the  SLCSE  is  being  implemented  in  a  series  of  eight 
incremental  builds  consisting  of  three  formal  deliveries.  The  final  delivery  from  General  Research  (GRC)  will  he 
designated  SLCSE  Version  3.0.  Versions  I.O  and  2.0  will  only  be  used  in-house  at  the  Rome  Air  Development 
Center  to  provide  effective  design  feedback  to  the  contractor.  It  is  intended  that  Version  3.0  will  be  a  relea.sable 
product.  The  second  point  is  that  the  Rome  Air  Development  Center,  a  US  AFSC  R  &  D  laboratory,  is  GRC.s 
direct  customer. 

(2)  The  primaiy  goal  of  the  current  SLCSE  development  effort  is  to  provide  the  environment  “framework"  (i,e.,  user 
interface,  project  database,  executive,  etc.)  within  which  software  development  tools  can  be  integrated.  While  the 
SLCSE  will  be  delivered  with  a  comprehensive  tool  set,  it  will  by  no  means  be  extensive.  The  SLCSE  will  be  used 
by  the  Rome  Air  Development  Center  to  support,  in  a  technical  way.  future  software  engineering  and  knowledge- 
based  R  &  D.  Because  of  its  state-of-the-art  life-cycle  project  database  component,  it  is  an  excellent  vehicle  for 
advancing  technology  in  areas  such  as  knowledge-based  systems,  project  management,  software  quality 
.specification,  data  collection,  quality  analysis/assessnvent.  automated  documentation  generation,  and  change 
impact  analysis. 

(3)  The  Rome  Air  Development  Center  also  has  potential  “customers"  for  SLCSE  who  are  involved  in  MCCR 
software  development  and  have  a  need  for  life-cycle  support.  Beyond  the  current  General  Research  contract,  it  is 
very  likely  that  the  SLCSE  will  be  enhanced  through  the  integration  of  necessary  tools  to  support  the  embedded 
sofware  development  needs  of  these  cu.siomers.  Tlie  first  likely  addition  will  be  support  for  M1L-STD-1750A. 
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DEVELOPMENT  OF  AN  AIRBORNE  FACILITY  FOR  ADVANCED  AVIONICS  RESEARCH 

by 

N.  van  £lrlal 

National  Aeroapac*  Laboratory  NLR 
P.O.  Box  90502.  1006  BM  Aaaterdaa. 

Itie  Netherlanda 


ABSTRACT 

The  present  generation  of  aircraft  is  equipped  with  a  nuaber  of  advanced  avionics  systems  like  digi¬ 
tal  Plight  Nanagement  or  Mission  Computers.  Flight  Control  Computers  and  Electronic  Flight  Instrument 
Systems  (EFIS) .  In  the  near  future  new  systems  may  be  introduced  as  the  Microwave  Landing  System  (MLS). 
Navstar  Global  Positioning  System  (GPS)  and  digital  data  link  systems  (SSR-Mode  S  or  vIa  satellites).  In 
order  to  derive  the  maximum  benefit  from  these  systems  new  procedures  will  have  to  be  developed.  Extensive 
simulator  and  Inflight  testing  Is  required  to  determine  the  optimal  use  of  the  new  avionics  systems  and  to 
establish  new  operational  procedures. 

The  Netherlands  National  Aerospace  Laboratory  NLR  performs  research  In  the  area  of  MLS  using  a 
moving-base  simulator  and  la  planning  to  use  Its  Fairchild  Metro  II  research  aircraft  for  airborne 
testing.  To  this  purpose  a  multi-year  program  has  been  started  called  ART  (Avionics  Research  Testbed)  In 
the  framework  of  which  the  aircraft  will  be  equipped  with  systems  Including: 

.  Programmable  Electronic  Flight  Instrument  System 
.  Programsiable  Plight  Management  Computer 
.  Programmable  Flight  Control  Computer 
.  Navstar  GPS 
.  MLS 

.  Digital  data  link. 

The  fully  equipped  aircraft  will  be  suited  to  perform  inflight  research  in  such  areas  as: 

.  establishing  MLS  procedures 

.  use  of  Navstar  GPS  as  a  navigation  and  approach  system 
.  conventional  and  unconventional  presentations  on  the  EFIS 
.  4-D  navigation. 

Flight  tests  with  the  system  developed  In  the  first  phase  of  the  ART-proJect,  based  on  EFIS  with  standard 
navigation  sensors,  are  scheduled  for  July  1987. 

LIST  OF  ABBREVIATIONS 

ADF  Automatic  Direction  Finder 

ADI  Attitude  Director  Indicator 

ART  Avionics  Research  Testbed 

ATC  Air  Traffic  Control 

BCP  Bezel  Control  Panel 

CDU  Control  Display  Unit 

DADC  Digital  Air  Data  Computer 

OEU  Display  Electronics  Unit 

DME  Distance  Measuring  Equipment 

DU  Display  Unit 

EFIS  Electronic  Flight  Instrument  System 

FCC  Flight  Control  Computer 

FCS  Flight  Control  System 

FMC  Flight  Management  Computer 

FMS  Flight  Management  System 

GP  Glide  Path  (ILS) 

GPS  Global  Positioning  System 

HSI  Horizontal  Situation  Indicator 

IAS  Indicated  Air  Speed 

ICAO  International  Civil  Aviation  Organization 

IFR  Instrument  Flight  Rules 

ILS  Instrument  Landing  System 

INS  Inertial  Navigation  System 

IRS  Inertial  Reference  System 

LOC  Localizer  (ILS) 

MLS  Microwave  Landing  System 

ND  Navigation  Display 

NLR  Netherlands  National  Aerospace  Laboratory 

PFD  Primary  Flight  Display 

PFS  Preclae  Position  Service  (CPS) 

RA  Radar  Altimeter 

RCP  Remote  Control  Panel 

RMDU  Remote  Multiplexing  Digitizer  Unit 

SPS  Standard  Position  Service  (GPS) 

S5R  Secondary  Surveillance  Radar 

VOR  VHF  Omnidirectional  Radio  Range 

I .  INTRODUCTION 

The  new  g«.neratlon  of  military  and  civil  aircraft  Is  equipped  with  a  number  of  advanced  avionics 
systems  as  Flight  Management  and  Flight  Control  Systems  and  Electronic  Flight  Instrument  Systems  (EFIS). 

In  the  near  future  new  systems  can  be  expected  to  be  Introduced.  Including  the  Microwave  Landing  System 
(MLS),  satellite  navigation  and  coonunlcatlon  systems  and  digital  data  link  systems  (SSR-Mode  S  and 
satellite  data  link). 
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la  coQjuucclOD  with  the  iatroductlon  of  theee  syeteas  new  procedures  and  air  traffic  control  (ATC) 
concepts  will  have  to  be  established  in  order  to  derive  maxiaum  benefit  froa  the  use  of  these  systens. 

For  exaaplef  in  case  of  MLS  nev  rules  and  procedures  are  required  for  the  definition  of  safe  and  fuel 
efficient  approach  paths  (even  during  equipment  aalfunctions) •  for  the  selection  by  the  pilot  of  his 
reference  approach  path,  for  Che  way  in  which  he  receives  and  uses  guidance  information,  and  for  ATC  for 
the  selection  of  different  approach  paths  within  the  MLS  approach  sector  for  the  mix  of  different  cate¬ 
gories  of  aircraft. 

The  use  of  EFIS  is  considered  to  be  an  Important  prerequisite  for  the  pilot  to  fly  a  complex  MLS 
approach.  It  may  be  anticipated  that,  especially  for  curved  or  segmented  approaches,  presentation  formatb 
will  be  required  quite  different  from  chose  presently  seen  on  Che  flight  deck.  An  important  consideration 
in  these  developments  is  that  Che  pilot  is  provided  with  safe  and  unambiguous  Information  with  regard  to 
his  reference  track  even  during  (MLS)  equipment  malfunctions. 

The  navigation  and  performance  management  potential  of  Plight  Management  Computers  (FMC)  exceeds  the 
capabilities  of  present-day  ATC  systems,  as  a  result  of  which  very  often  non-optlmal  profiles  are 
assigned.  In  addition,  Che  Increasingly  accurate  navigation  capabilities  achievable  tnday,  especlall}'  with 
Che  advent  of  satellite  navigation  systems,  call  for  a  more  flexible  route  structure  based  on  the  avai¬ 
lable  area  navigation  (RNAV)  capabilities. 

What  Is  required  is  a  nev  ATC-aircraft  relationship  with  Che  aircraft  indicating  to  the  ATC  system 
their  preferred  horizontal  (RNAV)  and  vertical  flight  paths,  based  on  an  individual  flight  profile  optimi¬ 
zation  in  the  PMC,  and  ATC  using  this  information  to  assign  a  flight  profile  to  a  particular  aircraft 
based  on  a  collective  optimisation  of  Che  total  traffic  situation.  A  digital  data  link  for  communication 
between  the  aircraft  (FMC)  and  the  ground  (ATC  computer)  is  an  essential  prerequisite  in  this  concept. 

Although  extensive  research  has  already  taken  place,  a  considerable  amount  of  testing  is  still 
required  to  support  the  realization  of  concepts  and  the  definition  of  procedures  in  the  areas  indicated 
here. 


Over  the  last  decade  the  Netherlands  National  Aerospace  Laboratory  NLR  has  been  involved  with 
research  in  many  of  the  areas  indicated  above.  For  example,  extensive  flight  simulator  research  has  been 
carried  out  to  support  the  definition  of  MLS  approach  procedures  (Ref.  1).  In  order  to  expand  the  capabi¬ 
lities  for  research  in  the  areas  discussed  above,  work  is  currently  under  way  at  NLR  to  realize,  besides 
the  moving  base  research  flight  simulator,  an  airborne  avionics  research  facility  and  an  ATC  research  simu¬ 
lator  (figure  1).  Coordinated  operation  is  aimed  for  by  carefully  attuning  the  capabilities  of  these  three 
research  facilities . 

For  the  development  of  the  airborne  facility  the  Avionics  Research  Testbed  (ART)  project  has  been 
created,  %rhich  is  the  topic  of  this  paper. 

2,  ART  SYSTEM  CONCEPT 

NLR  operates  two  research  airplanes:  a  Beechcraft  Oueen-Alr  and  a  Fairchild  Metro  II.  For  a  number  of 
reasons  (size,  payload,  operational  flexibility)  it  was  decided  to  use  the  Metro  airplane  (figure  2)  for 
the  ART-proJect. 

The  Metro  II  la  a  twin-engine  turboprop  airplane  with  a  gross  weight  of  14000  lbs,  operating  in  the  speed 
range  between  120  and  250  kts.  The  airplane  has  been  modified  extensively  for  aerospace  research  purposes. 

The  goal  of  the  ART-project  Is  to  equip  the  Metro  with  a  number  of  advanced  avionics  systems  in  such 
a  configuration  that  It  will  be  possible  to  perform  operational  research  on  the  use  of  these  systems. 

The  main  areas  for  application  of  the  ART-system  include: 

-  research  on  MLS  approaches  (e.g.  Interception  angles,  segment  lengths  and  orientations,  equipment 
requirements,  etc.), 

-  research  on  the  use  of  EFIS,  both  for  conventional  and  unconventional  presentations, 

-  research  on  the  use  of  digital  data  links, 

-  research  on  the  use  of  FMC's, 

-  research  on  the  use  of  satellite  navigation  systems  (e.g.  Navstar  GPS)  especially  for  RNAV  operations 
and  approaches. 

In  order  to  be  able  to  perform  research  In  these  different  areas  a  flexible  avionics  system  Is 
required  of  which  both  hardware  and  software  can  easily  be  adapted  to  the  requirements  of  the  particular 
test  objectives.  This  means  that  NLR  must  have  access  to  and  full  control  over  the  software  and  that  soft¬ 
ware  modifications  can  be  made  by  NLR.  The  consequences  of  this  requirement  are  discussed  In  the  next 
section. 

A  block  diagram  of  the  basic  system  Is  depicted  in  figure  3.  A  number  of  navigation  systems,  together 
with  an  attitude  reference  system  and  air  data  system,  provide  information  to  a  programmable  FMC.  Based  on 
this  Information  the  FMC  determines  the  aircraft  position  and  compares  it  to  the  desired  position  or 
desired  crack  derived  from  Che  flight  plan.  Differences  in  position,  altitude,  velocity  and,  in  case  of 
4-D  navigation,  time,  are  then  used  by  the  programmable  Flight  Control  Computer  (FCC)  to  generate  steering 
and  power  setting  commands  based  on  control  laws  for  the  airplane.  Steering  commands  are  presented  to  the 
pilot  on  the  Primary  Flight  Display  (PFD)  of  the  programmable  EFIS,  while  coupling  to  the  autopilot  may  be 
implemented  at  a  later  stage  of  the  program.  The  navigation  information  of  the  FMC  Is  plctorially 
displayed  on  the  second  EFIS  display,  called  the  Navigation  Display.  A  digital  data  link  system  is  inte¬ 
grated  with  the  FMC  while  a  digital  data  recording  system  is  installed  for  post  flight  analysis  of  test 
data. 

The  ART  system  is  a  research  tool  rather  than  a  standard  aircraft  avionics  package.  As  the  Metro 
airplane  is  used  also  for  other  research  projects,  it  was  a  requirement  from  the  beginning  that  installa¬ 
tion  of  the  ART  system  would  not  comprise  the  IFF  capability  of  the  airplane.  For  that  reason  Interaction 
between  the  ART  system  and  standard  avionics  systems  has  been  limited  to  the  maximum  extent  possible.  This 
consideration  also  resulted  in  the  decision  to  redesign  only  the  right  hand  side  of  the  cockpit  instrument 
panel  and  leave  the  left  hand  side  unchanged. 

3 .  MAJOR  SUBSYSTEMS 

The  research  concentrates  on  the  use  of  MLS,  GPS,  digital  data  link,  FMC/FCC  and  EFIS.  These  systems 
will  briefly  be  discussed  in  the  following  chapters. 
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3.1  MLS 

The  purpose  of  MLS  Is  to  provide  an  approach  and  landing  sysCen  with  Ijnproved  perfonnance  compared  co 
the  present  Instrument  Landing  System  (ILS).  Worldwide  replacement  of  ILS  by  MLS  is  scheduled  for  i998 
(Ref.  2).  The  major  advantages  of  MLS  are  that  It  does  not  have  the  siting  problems  of  ILS»  that  It  Is 
less  vulnerable  to  Interference  and  that  It  provides  the  capability  for  using  approach  paths  different 
from  the  single  straight  ILS  locallser/glldeslope  approach  path.  The  MLS  provides  accurate  proportional 
guidance  in  an  azimuth  sector  covering  at  a  maximum  40  degrees  on  both  sides  of  the  extended  runway  center¬ 
line  and  between  0.9  and  7.5  degrees  in  elevation  (Ref.  3).  Table  1  provides  some  information  on  the  advan¬ 
tages  of  MLS  over  ILS. 

The  aircraft  position  relative  to  the  runway  can  be  derived  from  Che  MLS  azimuth  and  elevation  infor¬ 
mation  together  with  range  Information  from  a  IttCE  or  precision  DME/P  station  or,  possibly,  from  GPS 
derived  positions. 

MLS  Includes  a  ground-to-air  digital  data  link  for  the  transmission  of  data  to  the  aircraft.  There 
are  two  categories  of  data,  basic  and  auxiliary.  The  basic  data  category  Includes  Information  regarding 
azimuth  and  elevation  coverage  supporting  simple  straight-ln  approaches  or  approaches  in  which  the  pilot 
delects  the  approach  azimuth  course  and  simple  missed  approach  procedures.  So  far,  the  auxiliary  data 
category  Includes  information  on  offsets  in  szlmuCh  end  elevation  antenna  position  and  In  DME  position,  to 
support  area  navigation  (RNAV)  operations.  However,  additional  auxiliary  data  word  capacity  Is  available. 
Some  additional  data  words  will  be  used  In  an  upcoming  application  of  the  ART  system  directed  towards 
research  on  a  procedural  MLS  Interception  procedure. 

In  the  Netherlands  the  civil  aviation  authorities  are  planning  to  Install  MLS  ground  equipment  for 
one  runway  at  Schlphol  Amsterdam  airport  in  1989  to  obtain  experience  with  th.;  system.  NLR  Is  at  the 
moment  exploring  the  market  for  airborne  MLS  equipment  with  the  aim  to  Integrate  MLS  Into  Che  ART- 
system  in  1988. 

3.2  Navstar  GPS 

The  Havscar  Global  Positioning  System  (GPS)  Is  a  satellite  navigation  system  that  provides  highly 
accurate  position,  velocity  and  time  information  Co  suitably  equipped  users  at  all  times  and  at  any  place 
on  or  near  the  earth.  It  Is  a  passive  system  which  means  chat  users  just  receive  information  and  do  not 
have  Co  transmit.  The  system  has  been  developed  by  Che  United  States  Department  of  Defense,  which  depart¬ 
ment  also  exercises  control  over  the  access  to  Che  system.  Only  authorized  users  will  have  access  to  the 
full  accuracy  of  GPS.  Table  2  gives  an  overview  of  Che  different  accuracies  available  (Ref.  4). 

Prototype  GPS  satellites  have  been  launched  since  1978  for  testing  purposes.  Navstar  GPS  la  currently 
scheduled  to  be  operational  by  1991  with  18  operational  satellites  in  orbit. 

The  present  constellation  of  prototype  (Block  I)  CPS  satellites  provides  ample  opportunity  to  use  GPS 
as  an  accurate  position  reference  system  for  a  number  of  projects  and  to  test  its  usefulness  for  such 
applications  as  low  level  operations  and  as  an  approach  system.  NLR  has  procured  a  civilian  (C/A-code) 
single  frequency  sequential  receiver  and  has  obtained  good  positional  accuracies  on  a  number  of  flights 
over  Che  Netherlands. 

It  must  be  noted  that  for  aviation  use,  be  It  military  or  civilian,  the  most  important  benefits  of 
GPS  are  derived  from  integration  with  other  navigation  systems,  especially  an  Inertial  Navigation  System 
(INS).  Research  with  the  ART  system  will  therefore  especially  be  directed  towards  the  use  of  GPS  as  part 
of  an  integrated  system 

3.3  SSR  Mode  S 

The  Secondary  Surveillance  Radar  System  (SSR)  as  In  use  today  has,  because  of  its  transmission  of 
Identification  and  altitude  datai  provided  a  considerable  Increase  in  the  safety  of  aviation  and  in  the 
capacity  of  the  ATC-system.  The  carriage  of  SSR  transponders  with  4096  codes  and  altitude  encoding  capa¬ 
bilities  has  become  mandatory  for  IFR  controlled  flights,  both  military  and  civilian.  In  many  areas  around 
Che  wucio. 

However,  the  Increase  In  traffic  has  resulted  in  difficulties  with  Che  operation  of  SSR  In  busy  areas 
(interference,  fruiting,  garbling,  overinterrogation,  airplanes  switching  codes,  etc.).  Although  modern 
techniques  may  solve  a  number  of  these  problems,  seme  of  the  difficulties  are  inherent  to  Che  present 
SSR  system. 

Two  methods  for  SSR  enhancement  have  been  approved  by  the  International  Civil  Aviation  Organization 
(ICAO)  to  satisfy  future  requirements:  the  first  one,  monopulse,  serves  to  improve  azlmuthsl  accuracy,  Che 
second  method  adds  a  selective  address  and  data  link  capability  (Mode  S)  (Ref.  5).  Besides  for  solving  the 
difficulties  encountered  with  Che  present  SSR  system  the  data  link  capability  could  prove  to  be  an  essen¬ 
tial  component  In  the  future  ATC  system  as  discussed  before.  Research  on  how  to  use  this  data  link  as  a 
cooBunlcatlon  medium  between  the  PMC  and  ATC  Is  required  and  is  one  of  the  potential  applications  of  the 
ART  system. 

3.4  Flight  Management  Computer 

One  of  the  Casks  of  the  programmable  Flight  Management  Computer  (FMC)  in  the  ART-syscem  la  to  provide 
a  flexible  Cool  for  performing  research  on: 

.  integration  of  new  sensor  systems  (HLS,  GPS,  SSR  Mode  S), 

.  pllot-FMC  communication, 

.  ATC-aircraf t  Integratlon/communlcatlon, 

.  EFTS  preprocessing,  especially  for  unconventional  3-dimen8lonal  preaenCatlons. 

The  fact  that  this  FMC  Is  used  for  research  Implicates  that  software  should  be  easily  accessible  and 
changeable.  For  this  reason  a  programmable  general  purpose  airborne  computer  Is  used  rather  than  a 
coomierclal  FMC.  The  emphasis  for  this  computer  is  on  navigation  management  rs’her  than  performance 
management, -as  the  latter  function  is  not  directly  within  the  scope  of  this  project.  Besides  navigation 
management  the  computer  also  Incorporates  a  number  of  FCC  functions. 

It  was  decided  to  use  a  ROLM  1664  computer  for  this  task  as  NLR  has  obtained  considerable  experience 
with  the  development  of  hardware  (Interfaces)  and  software  for  this  computer  In  the  on-board  data 
recording  system  developed  for  the  Fokker  50/100  certification  flight  test  programs.  The  ROLN  1664  Is  a 
16-blt  processor  with  a  64  K  words  core  memory  and  hardware  floating  point  processor. 
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3.5  EFIS 

The  progrsQBabIc  EPIS  used  in  the  ART  eystea  is  developed  by  Sperry  and  consists  of  two  Display  Units 
(DU)  with  Integral  Bezel  Control  Panel  (BCP),  a  Remote  Control  Panel  (RCP)  and  a  Display  Electronics  Unit 
(DEU) .  A  block  diagram  is  shown  In  figure  4. 

The  hybrid  (stroke/raster)  color  Display  Unit  has  an  active  area  of  6.5  x  6.5  inch  and  presents 
formats  based  on  data  from  a  number  of  aircraft  systems  that  is  processed  through  the  DEU.  The  DEU 
receives  sensor  data  through  ARINC  429  serial  data  inputs*  ARINC  708  weather  radar  data  through  a  1  MHz 
serial  data  Input,  and  source  selection  and  program  data  through  discrete  inputs.  The  BCP,  containing  16 
pushbutton  switches  plus  2  potentiometers  on  each  DU,  and  the  RCP  provide  great  flexibility  In  the  selec* 
tlon  of  different  display  modes  or  parameters  during  the  flight. 

The  formats  to  be  displayed  are  controlled  by  software  In  the  DEU.  Graphics  and  raster  data  Is  transmitted 
by  the  DEU  to  the  DU,  via  a  1  MHz  high  speed  serial  bus.  A  single  DEU  can  simultaneously  provide  primary 
flight  information  to  one  DU  and  navigation  information  to  the  other  DU.  Figure  5  shows  both  DU's  with  a 
representative  Primary  Plight  Display  and  Navigation  Dlaplay  format. 

The  unique  capability  of  this  EFIS  Is  that  the  display  format  is  In-^house  programmable.  The  system 
provides  the  flexibility  to  define  the  complete  composition  of  a  dynamic  display  In  terms  of: 

.  parameters, 

.  symbols  and  characters, 

.  symbol  location, 

.  parameter  priorities, 

.  colors. 

New  application  software  can  be  developed  by  NLR  person.iel  on  a  Software  Development  Station  after 
which  it  is  do%mloaded  to  the  DEU  through  an  IEEE“bus.  The  hardware  of  this  station  consists  of  an  IBM  AT2 
PC  with  co-processor,  20  Mbyte  hard  disk  and  1.2  Mbyte  floppy  drive,  a  monochrome  and  a  color  display, 
printer  and  tape  streamer.  The  software  environment  consists  of  a  number  of  programs  and  utilities  mainly 
provided  by  Sperry.  Figure  6  shows  some  of  the  hardware  of  this  Software  Development  Station. 

4,  PROJECT  PHASES 

Due  to  the  complexity  of  the  project,  the  variety  In  project  goals  and  the  differences  in  system  com¬ 
ponents  the  ART  project  has  been  divided  in  a  number  of  relatively  independent  phases.  The  following  pro¬ 
ject  phases  are  presently  foreseen: 

1.  Installation  and  operation  of  EFIS,  with  one  dlaplay  unit  for  dlaplay  of  primary  flight  information, 
and  supporting  systems, 

2.  Integration  of  the  Phase  One  system  with  NLR's  Flight  Management  Computer  (with  limited  capability) 

and  installation  of  the  second  EFIS  DU, 

3.  Integration  with  NavaCar  GPS, 

4.  Integration  with  MLS, 

5.  Integration  with  SSR  Node  S, 

6.  Provision  of  4-D  navigation  capability. 

Each  project  phase  will  be  concluded  with  a  short  flight  test  program  to  demonstrate  proper  operation  of 
the  system. 

The  schedule  for  the  realization  of  these  phases  Is  shown  in  figure  7.  The  first  phase,  that  Is 
currently  under  development,  will  be  ready  in  July  1987,  while  the  second  phase,  providing  a  limited  FMC 
capability  and  full  EFIS,  Is  scheduled  to  be  realized  by  April  J988.  The  integration  with  GPS,  MLS  and  SSR 
Node  S  will  occur  as  indicated  in  figure  7.  However,  this  schedule  may  be  changed  If  future  applications 
of  the  ART  system  require  so. 

5.  FIRST  PROJECT  PHASE 

The  first  phase  In  the  realization  of  the  ART-proJect  consists  of: 

-  Installation  of  one  EFIS  Display  Unit  in  the  right-hand  side  of  the  Metro  instrument  panel  for  display 
of  primary  flight  information, 

-  Installation  of  the  EFIS  DEU  and  required  sensor  systems  In  the  cabin, 

-  generation  of  sensor  signals  in  the  desired  ARINC  429  format  for  presentation  on  the  PFD. 

The  second  DU,  for  Che  display  of  navigation  information  will  be  Installed  In  the  second  project  phase 
when  Che  FMC  will  be  available. 

A  diagram  of  Che  systems  used  in  phase  one  Is  shown  In  figure  8. 

In  this  phase  Che  ROLH  1664  computer  is  used  for  conversion  of  the  analog  signals  from  the  different 
sensor  systems  to  the  ARINC  429  signal  format  required  by  the  EFIS.  Rather  than  having  a  number  of  ARINC 
700  series  systems  connected  to  their  dedicated  ports  on  the  DEU,  the  R0U1  computer  provides  one  serial 
ARINC  429  output  containing  Information  from  all  the  systems  chat  is  distributed  at  Che  front  end  of  the 
DEU  Junction  Box  over  the  respective  ARINC  Input  busses.  The  data  words  in  the  ARINC  output  are  identified 
by  the  proper  unique  ARINC  label  according  to  the  ARINC  700  series  specifications. 

As  a  Digital  Air  Data  Computer  (DAOC)  will  not  be  available  before  phase  two  of  the  project,  the  ROLK 
computer  also  contains  software  for  the  calculation  of  altitude,  indicate’  airspeed  (IAS)  and  vertical 
speed  based  on  measured  static  and  dynamic  pressures. 

As  shown  In  figure  8  the  Honeywell  IRS  (ARINC  704)  does  not  require  signal  format  conversion  and  can 
therefore  be  directly  connected  to  Che  EFIS  for  displaying  attitude  (roll,  pitch)  and  heading  information. 

The  Primary  Flight  Display  format  that  is  used  in  the  realization  of  phase  one  is  depicted  in  figure 
9  and  features  Che  full  basic  "T”:  attitude  director  indicator  (ADI)  with  flight  director  bars  framed  with 
speed  data  on  Che  left,  altitude  and  vertical  speed  on  the  right  and  horizontal  situation  indicator  (HSI) 
below.  ILS  glide  slope  deviation  Indication  is  sandwiched  between  ADI  and  altitude  tape,  with  radio  alti¬ 
tude  just  below  It. 

Table  3  lists  the  parameters  used  to  drive  this  display  with  their  ARINC  label  and  source. 
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Figure  10  and  11  show  the  cockpit  panel  lay-out  before  and  after  the  Installation  of  the  single  DO. 

As  can  be  seen  the  DU  Installation  was  accoanodated  to  a  large  extent  by  relocating  the  instruments;  it 
was  especially  Important  to  retain  the  HSI,  mounted  on  this  side  of  the  panel,  as  this  Instrument  is  used 
for  track  selection  In  this  phase  of  the  ART-proJect. 

After  the  realization  of  this  first  phase,  MLR  Is  under  contract  to  perform  research  with  this  system 
In  the  areas  of  EFIS  display  formats  and  MLS  interception  procedures.  For  this  last  application  the  system 
will  initially  be  expanded  with  an  accurate  position  determination  system,  simulating  MLS  until  KLS  air 
and  ground  equipment  becomes  available. 

6  SECOND  PROJECT  PHASE 

The  hardware  used  In  phase  two  is  based  on  the  phase  one  hardware  with  the  addition  of  the  second 
EFIS  DU,  DADC  and  cockpit  CDU.  The  cockpit  panel  lay-out  is  shown  In  figure  12.  The  software  development 
effort  for  the  FMC  has  been  started  already  and  Initial  software  has  been  created  for: 

-  flight  plan  generation, 

-  position  determination,  and 

-  calculation  of  track  deviation  errors  (both  lateral  and  vertical). 

A  computer  model  has  been  developed  for  an  IBM  AT  personal  computer  with  mcnochrcaie  and  color 
graphics  screens  for  the  generation  of  a  navigation  plan  (Flight  Plan).  Because  of  the  I/O  facilities 
available  It  Is  Intended  to  perform  most  flight  planning  activities  on  this  computer,  the  end  result  being 
a  floppy  disk  or  tape  that  will  be  downloaded  to  the  ROLM  1664.  Figure  13  shows  an  example  of  the  use  of 
this  system. 

For  the  In-fllght  position  determination  a  12-state  Kalman  filter  has  been  designed  based  on  an 
Inertial  Sensor  System  and  a  -generic-  position  fix  system.  Furthermore,  software  has  been  developed  for 
the  processing  of  flight  plan  Information  and  for  the  computation  of  differences  between  the  desired 
flight  Crack  and  actual  aircraft  position. 

7.  CONCLUSIONS 

The  technical  development  of  avionics  systems  cakes  place  at  a  high  rate.  However,  the  advantages  to 
be  gained  from  these  systems  can  only  be  realized  if  safe  and  proper  procedures  for  the  use  of  these 
systems  In  relation  to  Air  Traffic  Control  can  be  established.  One  of  the  activities  required  to  support 
the  establishment  of  procedures  Is  airborne  research. 

Based  on  lea  flight  test  and  simulator  experience  NLR  has  started  the  development  of  such  an  airborne 
avionics  research  facility.  In  the  framework  of  Che  Avionics  Research  Testbed  (ART)  project  NLR's  Metro 
research  airplane  Is  being  equipped  with  a  number  of  advanced  avionics  systems.  Including  a  programmable 
EFIS,  prograansble  FMC,  MLS,  GPS  and  SSR-Mode  S.  The  development  of  the  first  phase  of  Che  project, 
related  to  the  installation  of  EFIS,  la  well  under  way  and  Is  scheduled  to  be  finished  by  this  summer, 
after  which  Che  system  will  be  used  In  s  number  of  projects.  The  total  ART  capability  is  scheduled  to  be 
available  by  1989. 
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TABLE  1 

Coaparison  of  MLS  and  ILS 


OPERATING 

108  -  112  MHz  (LOC) 

5031  -  509C  MHz 

FREQUENCY 

328  -  335  KHz  (GS) 

NR  CHANNELS 

40 

200 

APPROACH 

ONE 

MULTIPLE,  SELECTABLE 

PATH 

STRAIGHT  IN 

SEGMENTED  APPROACH  CAPABILITY 

ENVIRONMENTAL 

500  M  FLAT  AREA 

NO  SPECIAL 

REQUIREMENTS 

IN  FRONT  OF  GS  ANTENNA 

REQUIREMENTS 

MULTIPATH 

PROBLEM 

NO  SIGNIFICANT  PROBLEM 

ANTENNA 

LOC  15  -50  m  WIDE 

A2IM.  2.5  X  2.5  m 

SIZE 

GS  10  m  HIGH 

ELEV.  3  m  HIGH 

DATALINK 

NO 

YES 

CAPABILITY 

TABLE  2 

GPS  Accuracies 


PPS 

SPS 

Position 

Altitude 

Velocity 

Time 

18  m  (2  DRMS) 

28  0  (95Z) 

0. 1-0, 5  n/Sec 

180  nsec 

100  o  (2  DRMS) 
157  D  (95Z) 

0.5  m/Sec 

385  nsec  (95Z) 

TABLE  3 

EFIS  input  parameters  for  AKT  Phase  i 


nr.  parameter 

ARINC  source- 
label 

a/c  source 

1  pitch 

704-324 

IRS 

2  roll 

704-325 

IRS 

3  track  angle 

704-313 

IRS 

4  magn,  heading 

704-320 

IRS 

5  baro  corr.  alt. 

706-204 

A/C 

6  Ind.  airspeed 

706-206 

A/C 

7  rate  of  cllab 

706-212 

A/C 

8  VOR  bearing 

711-222 

A/C 

9  VOR  sel.  radial 

711-100 

A/C 

10  DME  distance 

709-202 

A/C 

11  ADF  bearing 

712-162 

A/C 

12  ILS  loc.  dev. 

710-173 

A/C 

13  ILS  GS  dev. 

710-174 

A/C 

14  radio  altitude 

707-164 

A/C 

15  Plight  Director  roll  7^1-140 

A/C 

16  Flight  Director  pltct  .^>1-141 

A/c 

17  baron,  setting 

706-234 

ROLM 

18  decls.  height 

701-170 

ROLM 

19  selec.  heading 

701-101 

A/C 

20  max.  all.  airsp. 

706-207 

ROLM 

21  selec.  airspeed 

701-103 

ROLM 

22  selec.  altitude 

701-102 

ROLM 

23  sel.  runw.  head. 

701-105 

A/C 

24  outer  marker 

701-222 

A/C 

23  middle  marker 

1 

701-222 

A/C 

FMC  FLIGHT  MANAGEMENT  COMPUTER 
FCC  FLIGHT  CONTROL  COMPUTER 

TCC  THRUST  CONTROL  COMPUTER 


EFIS  ELECTRONIC  FLIGHT  INSTRUMENTS 


Ftg.  3  Art  Concept 


SENSORS  AND  SYSTEMS 


Fig.  4 


EFIS  Color  Display  Systea. 


fig.  Sa:  PrlBUiry  Flight  Display 


Fig.  5b:  Navigation 


Fig.  6  Picture  of  EFIS  Software  Developnent  Station 
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DISCUSSION 


W.R.Fried,  US 

( 1 )  Do  you  have  any  comments  on  the  incompatibility  between  the  altitude  measured  by  GPS  (above  the  geoid)  v  ersus 
the  altitudes  needed  for  air  traffic  control  (i.e..  barometric  or  pressure  altitudes)? 

(2)  Could  GPS  time  be  used  for  the  fourth  dimension  in  air  traffic’  control  in  the  future  ’ 

Author's  Reply 

( 1 )  GFS  provides  very  accurate  horizontal  positions.  V'ertical  accuracy.  ht>'^cvci.  is  iiol  as  gt)od.  Civilian  users  mav 
obtain  »  1 50  m  I  o  in  altitude.  This  does  not  provide  much  advantage  over  barometric  altitude. 

(2)  It  certainly  can.  but  it  may  be  an  i>verkill  in  accuracy.  Also,  then  everybody  would  have  to  use  GPS  to  operate  in 
the  same  lime  frame. 


ATELIERS  DE  CONCEPTION  DE  SYSTEMES  AVIONIQLES 
£T  DE  REALISATION  DE  LOGICIELS  EMBARQUES 


3h-l 


par 

Monique  Slissa 

Aerospatiale  Division  Helicopteres 
el 

Philippe  Laroche-Levy 
Avions  Marcel  Dassault 
Quai  Marcel  Dassault 
92214  Si  Cloud 
France 


La  qualite  globale  d’un  systeme  avionique  complexe  depend  lar^  >  ent  oes  choix  de  principe  qui  doivent  etre  fails 
tot  dans  le  cycle  de  developpement.  Ceci  justifje  I'emploi  sysiematique  de  mojens  adaptes  des  ce  stade  et  tout  au 
long  do  cy<  !e  de  vie. 

Corrtme  support  aux  methodologies  dc  conception  et  de  realisation  de  systemes  qui  sent  presentees  dans  I'expose 
cite  en  reference  1,  il  est  done  necessaire  de  meitre  en  oeuvre  des  moyens  permettant  d'elaborer  ei  de  maTtnser. 
tout  au  long  du  cycle  de  developpement  ei  de  vie  : 

-  La  definiton  d'un  systeme 

C’est  I'objet  de  I'ATELIER  SYSTEME. 

-  La  realisation  des  logiciels  embarques 

C'est  I'objet  de  I'ATELIER  LOGICIEL. 


Dans  ia  suite  du  propos.  (es  points  suivants  ^eront  examines  : 

•  La  demarche  conduite  par  les  avionneurs  AEROSPATIALE  et  AVIONS  MARCEL  DASSAI.  LT 

•  La  notion  d'atelier 

•  L'lmplantation  lodustnelle  des  ateliers 

•  L’Atelier  Systeme 

•  l.'Aielier  LogK'tel 

•  Les  communications  entrt*  ( es  ateliers 

1  -  LA  DEMARCHE  CONDUITE  PAR  LES  AVIONNEURS  AEROSPATIALE  ET  AVIONS  MARCEL  DASSAULT 

Pour  le  developpement  des  systemes  avioniques  de  leurs  precedents  programmes  a^imnautiques. 

1' AEROSPATIALE  et  les  AVIONS  MARCEL  DASSAULT  ont  utilise  des  outillages  informatiques,  en  particulier  pour 
ce  qui  est  de  : 

-  la  definition  fonctionnelle  des  systemes 

-  la  specification  des  traitements  “temps  reel" 

-  la  gestion  de  configuration  des  systemes  et  des  logiciels  embarques 

-  la  documentation  associee  aux  eiapes  de  conception  et  de  realisation. 


Ces  societes,  sous  I'egide  du  Ministere  Fran<;ais  dc  la  Defense,  ont  largement  contnbuc  a  la  definition  de  moyens 
performants  couvrant  le  cycle  de  conception  d’un  systeme  et  de  realisation  des  logiciels  embarques  qui  y  sont 
inclus. 

Comme  cela  a  ete  explique  dans  I'expose  cite  en  reference  1.  ces  travaux  ont  ete  conduits  en  collaboration  avec  la 
communaute  avionique  fran<;aise,  dans  le  cadre  de  I'etude  ITI  a  laquelle  prennent  part,  avec  AEROSPATIALE  et 
AMD-BA^  les  societes  suivantes  ;  CROUZET,  Electronique  Serge  DASSAULT,  SAGEM,  SFENA,  SFIM  et 
THOMSON-eSF. 

lls  ont  abouti  au  developpement  de  deux  entites  conformement  a  un  processus  de  conception  descendant  : 

•  un  ATELIER  SYSTEME  et 

•  un  ATELIER  LOGICIEL. 


Ces  ateliers  doivcnt,  en  outre,  repondre  aux  besoins  de  communication  entre  les  activites  qu'ils  supporters 
respectlvement.  Ceci  doit  permettro  de  garantir  la  coherence  de  cet  ensemble  qui  constltue  le  Systerrie  de 
Developpement  d'Avionique  ITI  (SDA  ITI). 
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Les  deveJoppements  du  SDA  IT],  actuellement  en  cours,  ont  pour  objectifs  la  mise  en  oeuvre  et  I'utilisatjon  de  ces 
ateliers  dans  ies  prochains  programmes  aeronautiques  qui  impliquent  des  membres  de  la  communaute  industrielle  de 
I'avionique  frangaise. 

2  -  LA  NOTION  P’ATELIER 

Le  terme  d"'ATELlER",  choisi  pour  designer  les  deux  grands  ensembles  composant  les  moyens  d’etude  et  de 
developpement  de  systemes  qui  sont  Tobjet  du  present  propos,  met  I'acceni  sur  des  notions  dont  il  faut  souligner 
['importance.  EUes  sent  plus  particulierement  relatives  a  la  structure  inlormatique  de  I'ateher. 

•  Chaque  ensemble  qualifie  d'"ATELIER",  comprend  un  certain  nombre  d'ouiils  logiciels. 

Ceux-ci  peuvent  etre  utilises  independamment  ies  uns  des  autres  et  meme  en  ignorant  la  structure  de 
I'atelier.  En  effet,  ils  sont  congus  pour  supporter  les  taches  relatives  a  une  phase  specifique  du  develop¬ 
pement  d'un  systeme.  II  ne  s’agit  done  pas  d'un  ensemble  informatique  monolithique. 

•  Par  ailleurs,  chaque  atelier  n'est  pas  seulement  constitue  par  la  juxtaposition  d'outils  qui  s'lgnorent. 

Au  contraire,  chaque  outil,  meme  s'll  peut  fonctionner  sans  utiliser  tous  ies  autres  services  de  I'ateljer,  est 
adapte  : 

Pour  pouvoir  recevoir  des  informations  en  provenance  d’autres  outils  de  I'atelier  ainsi  que  pour  en  fournir 
lui-m^me,  conformement  a  sa  fonctionnaiite  et  selon  un  processus  d’enrichissement. 

Pour  permettre  la  preparation,  le  suivi  et  la  gestion  des  evolutions  des  "produits"  qui  sont  elabores  avec 
son  aide  dans  le  cadre  d'un  programme  avionique. 

Ainsi,  un  "ATELIER"  est  bien  un  ensemble  d’outils  logiciels  dont  I'un  couvre  la  fonction  particuliere  d'assurer 
I'integration  entre  tous  les  autres.  Get  outil  appele  "STRUCTURE  D’ACCUEIL",  constitue  ainsi  la  structure  de 
base  de  I’atelier,  a  travers  laquelle  les  utiiisateurs  accedent  aux  outils  specialises  en  gerant  les  activites  liees  aux 
autres  outils  et  assure  une  gestion  coherente  au  sein  de  I'atelier,  en  particulier  au  sens  de  : 

•  la  circulation  des  donnees  entre  outils 

•  du  suivi  des  evolutions  des  systemes  deveioppes. 

A  ce  point,  Ton  peut  ajouter  deux  remarques,  qui  sont  consequences  des  definitions  donnas  ci-dessus  et  concernent  la 
realisation  informatique  des  ateliers  : 

•  Les  outils  logiciels  d'un  atelier,  attaches  aux  travaux  specifiques  d'une  phase  d’etude  ou  de  developpement 
gerent  chacun  les  donnas  ejui  sont  propres  a  I'activite  qu’ils  sous-tendent.  La  structure  d'accueil.  de  son  cote, 
gere  les  informations  liees  a  sa  fonction,  sans  redondance  avec  les  outils,  mais  en  liaison  avec  eux. 

•  Comme  cela  a  ete  dit,  les  outils  logiciels  doivent  etre  adaptes  au  mode  de  fonctionnement  tnte|re  de  I'atelier. 
Cela  signifie  que  des  outils  existants  peuvent  subir  [’adaptation  necessaire  sans  qu'il  faille  recreer  de  toutes 
pieces  un  outillage  informatique  offrant  des  fonctionnaiites  equivalentes.  Certains  outils  du  Systeme  de 
Developpement  d'Avionique  qui  seront  mentionnes  plus  loin,  sont  dans  ce  cas. 

Ces  deux  points  mettent  cn  relief  I’ouvcrturc  informatique  au  sens  d’une  cumpaiibilite  aA*.endanie  qui  esi  le  fait 
des  ateliers  qui  vont  etre  decrits. 


3  -  LMMPLANTATION  INDUSTRIELLE  DES  ATELIERS 

Le  decoupage  des  moyens  de  developpement  de  systemes  en  "ATELIER  SYSTEME"  et  "ATELIER  LOCICIEL",  munis 
des  capabilites  de  communication  necessaires  dont  la  nature  sera  explicitee  plus  Join,  correspond  a  ceJui  des 
tUches  a  faire  par  les  industriels  imptiques  dans  un  programme  d'avionique. 

En  effet,  .  \telier  Systeme  supporte  les  travaux  de  conception  et  de  specification  du  systemier.  L'Atelier  Logiciel, 
quant  a  lui,  supporte  les  travaux  de  realisation  des  logiciels  embarques,  principalement  effectues  par  ies  industriels 
equipementiers,  mais  aussi  dans  certains  cas,  un  avionneur  pour  les  logiciels  assurant  la  gestion  du  systeme,  par 
exemple. 

Sur  ce  point,  Ton  peut  faire  les  remarques  suiyantes  : 

•  L'implantation  industrielle  de  ces  moyens  peut  dependre  du  type  de  cooperation  imposee,  dans  le  cadre  d'un 
programme  d'avionique,  a  tous  les  partenaires  (clients,  avionneurs,  ^uipeinentiers). 

•  Quelies  que  soient  Ies  relations  etablies  entre  les  piartenaires  d’un  programme  et  aussi  chez  le  meme 
industriel  (si  tel  est  le  cas),  les  equipes  de  definition  des  systemes  d'une  part  et  celles  de  realisation  des 
logiciels  d'autre  part  sont  par  la  nature  meme  de  leurs  travaux,  differentes  et  nettement  separws. 

Ceci  justifie,  cn  tout  cas,  la  separation  des  moyens  en  deux  ensembles  pouvant  s'echanger  les  informations 
n^essaires  a  la  conduite  des  travaux. 

•  II  apparait  evident,  dans  le  cadre  d’un  programme  d’avionique  donne,  que  I'Atelier  Systeme,  permettani  au 
systemier  de  maftriser  la  definition  de  i'ensembJe  du  systeme,  vis  a  vis  de  son  client,  doit  etre  unique  ;  ceci 
est  ^alcment  vrai  meme  si,  dans  les  faits,  le  "systemier"  est  compose  de  plusieurs  industriels  cooperants. 

Par  contre,  il  est  tout  aussi  clair,  qu’au  niveau  de  la  realisation  des  logiciels,  la  composante  "Atelier  Logiciel" 
est  susceptible  d'avoir  plusieurs  variantes,  liees  au  contexte  industriel  et  a  la  nature  des  logiciels  a  developper. 
Ce  qu'il  est  important  d'assurer,  dans  ce  ca$-Ia,  afin  de  garantir  la  coherence  des  developpements  dans  le  cadre 
du  programme  considere,  e'est 


-  Une  methodologie  commune  pour  ies  divers  Ateliers  Logiciels, 

-  DCS  communications  eifiraces  entre  I*  Atelier  Systeme  et  chaque  Atelier  Logicjel. 

4  -  L*ATELIER  SYSTEME 

11  ne  s'agit  pas  de  reprendre  ici  une  description  detaiHee  de  la  methodologie  de  conception  ei  de  definition  d'un 
systeme  avionique.  Cela  est  expose  dans  le  propos  cue  en  reference  1.  Mais,  ceile-ci  etant  acquise,  I'on  va 
decrire  precisement  ci-dcssous  I'ensemble  des  moyens  qui  en  constituent  le  support  :  L'ATELIER  SYSTEME. 

En  premier  lieu,  seront  enumer^s  Ies  fonctionnalites  attendues  de  I'Atelier  Systeme  ;  ensuite  les  ounls  majeurs  de 
I'Ateiier  Systeme  ITI  seront  presentes  ;  enfin  les  caracieristiques  les  plus  irnportantes  de  son  implantation 
informatique  seront  indiquws. 


4.1.  Les  fonctionnaiit^  atterxiues  de  1* Atelier  Systeioe 

Elies  sont  de  plusieurs  natures  : 

4.1.1.  La  mise  en  oeuvre  de  la  methodologie  de  dcvelc^pement  d’un  systeme  avionique. 

L'Atelier  Systeme  doit  offrir  des  outils  Jogiciels  couvrant  toutes  les  etapes  du  cycle  de  conception  d'un 
systeme,  chaque  outillage  informatique  etant  adapte  aux  travaux  specifiques  d'une  phase. 

On  peut  rappeler  ici,  de  maniere  macroscopique  que  les  etapes  principales  sont  les  suivantes  : 

•  elaboration  des  specifications  globales  des  fonctions  operationnelles 

•  determination  de  I' architecture  fo«'<'tionne!!e 

•  superposition  du  decoupage  fonctionnel  sur  I’architecture  physique 

•  specifications  detaiilees  des  fonctions  operationnelles  et  des  iraitements  effectues  dans  les 
equipements 


4.1,2.  L'obTcntion  de  specifications  dc  qualite 

L'Atelier  Systeme  doit  pouvoir  etre  le  garant  d’un  haut  nr  eau  de  qualite  pour  les  specificationa  ?iaborees 
avec  son  support, 

Ceci  signifie,  en  particulier,  que  les  outils  logiciels  doivent  implementer  de  maniere  ngourcuse  les 
methodes  de  travail  prealablemeni  choisies.  II  faut,  egalemcnt,  qu'ils  permettent  d'assurer  un  maximum  de 
controles  de  coherence  a  chaque  niveau  de  Reification. 

L'Atelier  Systeme,  surtout  a  travers  les  fonctions  propres  a  la  Structure  d'Accueil,  doit  faciliter  la  prise 
en  rompte  des  specificites  liees  a  chaque  programme  d’avionique,  comme  la  structure  de  la  documenta¬ 
tion,  les  circuits  de  decision  et  ceux  de  diffusion  tout  en  garantissant,  apres  Jeur  definition,  leur 
strict  respect  pendant  les  travaux  mettant  en  oeuvre  I'atelier. 


4.1.3.  La  maitnse  des  evolutions  de  la  definition  d’un  systeme  avionique 

La  maTtrise  des  evolutions  de  la  definition  d'un  systeme  complexe  implique  en  particulier  la  mise  en 
oeuvre  de  moyens  efficaces  pour  assurer  correctement  : 

•  La  gestion  des  fiches  d'evolution,  elabor^s  au  niveau  global  du  systeme  : 

-  leur  initialisation  et  la  determination  de  I'impact  qu'elles  ont  au  niveau  des  produits  de  I'atelier 
qui  sont  a  la  base  des  documents  de  ^>ecification, 

-  leur  instruction  a  une  profondeur  suffisante  pour  permettre  d'evaluer  leur  repercussion  en  routs  et 
delais, 

-  leur  prise  en  compte  apres  une  d^ision  favorable, 

•  La  gestion  de  configuration  du  systeme  et  la  connaissance  des  applicabilites  des  fiches  d'evolution  et 
la  definition  des  etats,  standards  et  versions  du  systeme. 


4.1.4.  La  gestion  de  la  diffusion  des  informations 

L'Atelier  Systeme  doit  prendre  en  compte  les  rapports  entre  les  differents  intervenants  dans  un 
programme  d'avionique  :  les  clients,  les  Services  Officiels  et  Centres  Etatiques  concernes,  le  systemier. 
I'ensemble  des  cooperants  ...). 

A  ce  titre,  il  gere  la  diffusion  entre  les  differents  partenaires  (documents  de  specification,  fiches 
d'evolution  ...). 


4.1.5.  La  mise  a  disposition  d'un  ensemble  de  moyens  adaptes  au  niveau  des  utilisateurs  concernes  et  au  mode  de 
travail  requis  par  la  methodologie  employee. 
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En  effet,  I'Atelier  Sysieme  est  destine  a  ^tre  utilise  par  des  personnels  de  qualification  elevee  (chefs  de 
projet,  ingenieurs  concepteurs,  ...).  II  doit  done  presenter,  dans  ses  differentes  fonctions  des  interfaces 
"Homme-nnachine"  adapt^s.  De  plus,  pour  les  phases  de  travail,  menws  au  sein  d’equipes  de  conception, 
les  outils  concernes  doivent  avoir  des  capacity  "multiutilisateurs"  puissantes  afin  d'assurer  en  permanence 
la  coherence  de  la  definition. 

4.2.  Les  outils  majeurs  de  i*Atelief  Systciwe 

Les  outillages  informatiques  qui  sont  d^rits  ci-dessous  font  partie  de  i’Atelier  Systeme  inclus  dans  le 
Systeme  de  Developpement  d'Avionique  Ul. 


4.2.1.  L’Qutil  de  Conception  Systeme  PCS 


a)  Obiet  d'OCS 

La  specification  de  I'architecture  fonctionnelle  d'un  systeme  est  supportee  par  un  outil  d’analyse 
descendante,  OCS. 

L'objet  principal  de  cet  outil  est  de  conduire  a  I'identification  des  paves  fonctionneis  et  au  recensement 
des  interfaces  entre  ceux-ci  dans  la  demarche  d'analyse  fonctionnelle  d'un  systeme  dont  la  complexjte 
pcut  etre  variable.  Cet  outil  supporte  I'analyse  de  type  IDEFO,  mais  a  la  souplesse  necessaire  pour  etre 
utilise  en  prenant  en  compte  I'organisation  du  travail  propre  a  chaque  industnel. 

b)  Concepts  manipules  par  OCS 

Les  concepts  pris  en  compte  sont  principalement  les  suivants  : 

*  Les  boftes  : 

Elies  constituent  la  representation  graphique  d'un  objet  dont  la  semantique  correspond  a  la  decom- 
posiiiori  du  systeme  et  qui  represente  une  activite  du  systeme. 

-  Les  flots  : 

Ils  sont  le  regfoupement  sous  un  seui  nom  d'informations  ayant  une  caracteristique  commune.  Leur 
'•epreseniaiion  graphique  est  une  fleche. 

On  rencontre  done  les  cas  particuliers  qui  sont  illustres  sur  la  fiche  1  ; 

.  Un  floi  de  commandesestun  regroupement  d’informations,  controlant  au  sens  d'lDEFO.  I'activite 
representee  par  la  botte  a  laquelle  il  est  relatif. 

.  Un  flot  d'entree  est  un  regroupement  d’informations  utilises  en  entr^  de  i'activite  represeniee  par 
la  boTte  concernee. 

.  Un  flot  de  sortie  est  un  regroupement  d'informations  elaborees  par  I'activite  de  la  fonction  represen¬ 
tee  par  la  botte  concernee. 

.  Un  flotdemecanismes  est  un  regroupement  d'informations  (ressources  au  sens  d'lDEFO),  permettant 
I'activite  de  la  fonction  representee  par  la  bdite  a  laquelle  il  est  relatif. 

-  Les  informations  : 

Ce  sont  les  donnees  transitant  entre  plusieurs  elements  de  la  decomposition.  Elies  appartiennent 
toujours  a  un  flot  dont  elles  reprennent  I'attribut  (entrw,  sortie,  ...). 

-  Les  dependances  fonctionnelles 

Ce  sont  les  dependances  entre  les  informations.  Ainsi  que  cela  est  schematise  sur  la  ':^ure  1,  pour 
chaque  information  de  sortie  sont  indiques  les  liens  avee  les  informations  revues  permettant  de 
I'elaborer. 


c)  Fonctionnalites  d’OCS 

La  methode  d’analyse  structuree  hierarchique  descendante  qui  a  ete  choisie  (voir  figure  2)  permet  : 

.  de  commencer  par  la  description  la  plus  generale  du  systeme 

.  de  determiner  ensuite  les  interfaces  entre  les  differents  elements  en  raffinant  la  definition  tout  au 
long  de  la  decomposition 

.  de  terminer  la  d^omposition  en  completant  I'architecture  au  fur  et  a  mesure  de  I'avancement  du 
travail  par  un  processus  iteratif. 

On  precede  done  a  un  decoupage  fonctionnel  iteratif,  dans  un  contexte  de  multiutilisation  approprie  aux 
equipes  de  conception,  qui  assure  en  outre  une  propagation  ascendante  et  descendante  des  informations. 

Les  principales  fonctions  de  I'outil  sont  les  suivantes  : 
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.  Des  /onctions  de  creation^  modification  et  destruction  de  diagrammes  et  d'elements  de  diagrammes 
permettani  de  saisjr,  de  maniere  adaptee  au  mode  de  travail  des  utilisaieui s,  les  donnees  manipulees 
dans  I'outii. 

.  Une  fonction  dite  "configuration  de  I'outii"  qui  permet  de  determiner  pour  cheque  type  d'usage,  sj 
cela  est  necessaire,  des  parametres  d'utilisation,  qui  seront  pris  ensuite  par  delaut  (comme  ies  tallies 
maximales  des  noms  de  boites,  de  flots,  ...  ou  les  champs  reserves  aux  attribuis  des  informations  ...) 

.  Des  controles  assurani  la  coherence  des  travaux  realises  sous  Toutil.  11s  peuvent  revetir  divers  modes 
libre  ou  assiste,  en  temps  reel  ou  differe. 

.  Des  aides  au  travail  en  multiutilisation  qui  instaurent  des  dialogues  intelligents  entre  les  utilisateurs 
d'une  m^me  equipe  de  conception  et  permettent  une  utilisation  simple  des  elements  de  la  decompo¬ 
sition  specifies  par  d'aurres. 

11  s'agit  en  particulier  de  pouvoirmesureren  "temps  reel"  I'lmpact  d'une  modification  et  I'ampleur 
de  sa  propagation  le  long  d’une  chaTne  fonctionnelle. 

.  La  constitution  et  la  manipulation  d'arbres  et  de  sous-arbres  : 

Dans  un  but  de  recu.'ierabiiite,  des  fonctions  d'accrochage  et  de  decrochage  d'arbres  et  de  sous-arbres 
sent  mises  en  oeuvre  avec  les  verifications  de  coherence  et  de  completude  necessaires  pour  en  rendre 
I'usage  valide. 

.  La  gestion  des  evolutions  dans  laquelle  le  but  poursuivi  est  d'utiliser  I'intelligence  de  I'outii  pour 
preparer  les  modifications  avec  la  connaissance  des  fiches  en  etude  et  formuier  les  etais  modifies 
definitivement  apres  la  decision  d'application  relative  a  une  "version"  du  systeme. 

.  Le  couplage  a  la  Structure  d'Accueil  Systeme. 

d)  Produits  realises  a  I'aide  d'OCS 

Lorsque  les  travaux  relatifs  a  la  specification  de  I’architecturc  fonctionnelle,  supportee  par  CCS.  sont 
termines,  t'oo  a  obtenu  *. 

.  La  decomposition  du  systeme  en  plusieurs  niveaux  rorrespondant  a  differentes  categories  de  rnodules 
fonctionncls 

.  La  determination  des  flots  de  donnees  iransitant  entre  les  di/ferents  elements  de  ia  decomposii/on 
.  La  specification  detaillee  des  interfaces 
.  La  definition  des  chaTnes  tonctionnelles  du  systeme. 

Les  produits  en  sortie  H’OCS  ont  a  la  fois  des  composantes  graphiques  et  textuelles  dont  I'assemblage 
coi.-Stitue  les  documents  de  specifii'ation  fonctionnelle  d'un  systeme. 

4.2.2.  Les  outits  de  speciftcatton  detaillee 

4.2.2. !.  DLAO  (Definition  de  Logiciel  Assistee  par  Ordinateur) 

alObiet  de  DLAO 

II  s'agit,  aver  cet  outil.  de  fame  la  redaction  des  specifications  detaillees  des  fonctions  operation- 
nelles  et  de  specifier  les  traitements  qui  y  interviennent  et  les  test  associes. 

L 'orientation  de  I'outii  vers  la  prise  en  compte  des  aefivites  a  caractere  temps  reel  le  predispose 
particulierement  a  une  utilisation  dans  la  definition  des  systemes  avtooiques. 

biConcepts  maniputes  par  DLAO 

Les  donnees  d'entr^  de  I'outii  sent  constituecs  par  les  interfaces  et  les  chaThes  fonctionneiles  du 
systeme  definies  avec  I'Outil  de  Conception  Systeme,  dans  une  etape  precedente. 

La  specification  est  redigee  a  I'aide  d'un  langage  formel  manipulant  les  cinq  types  d'objets  suivants  : 

.  Les  traitements 

Ce  sent  les  taches  accomplies  par  le  pave  logiciel  a  specifier.  La  description  sc  fait  en  utilisant 
des  mots-cles  (faire,  sequence,  tant  que,  si,  alors,  ...).  Elle  comporte  notamment  : 

-  ['introduction  des  donnws  d'entr^ 

-  I'identification  des  donnees  en  sortie 

-  la  liste  des  evenements  agissant  sur  le  traitement 
'  ies  contraintes  de  realisation  qui  sent  imposes. 

La  definition  d'un  traitement  exprime  son  comportement  dynamique  qui  se  traduit  par  exemple  par 
I'af fectation  d'informations,  le  declenchement  d’evenements,  ... 
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.  Les  informations 

Ce  sont  les  donnas  operaiionnelles  manipul^s  par  les  traitements.  Elies  peuvent  etre  elementajres 
ou  composees  d'autres  informations. 

•  Les  evenements 

Ce  sont  les  faits  dont  I'arrivee  aJeatoire  ou  cyclique  activent  ou  conditionnent  un  traitement. 

•  Les  etats 


Ce  sont  les  elements  statiques  intervenant  dans  un  traitement  ou  qui  s'en  deduisent. 
•  Les  interlaces 


Ce  sont  les  representations  physiques  des  informations  dont  la  description  precise  est  indispensable 
pour  les  phases  suivantes  du  developpement. 

c)  Fonctionnalites  de  DLAO 

Les  principales  fonctions  de  I'outil  sont  les  suivantes  : 

-  La  saisie  interactive  et  I'analyse  des  objets  prenant  part  a  une  specification,  bas^  sur  I'utilisation 
d'un  langage  forme! 

-  L'analyse  et  I'execution  de  requetes  relatives  aux  objets  deja  memorises  pour  en  obtenir  une 
representation  graphique  ou  textuelle 

-  Les  controles  de  coherence  appliques  aux  specifications 

-  Une  structure  documentaire  permettant  : 

•  La  definition  de  plans-types  de  specification  adaptes  aux  besoms  des  utilisateurs 

«  L'elaboration  des  documents  de  specification,  respectant  les  plans  -  types  definis 
prealablement 

-  La  gcslion  des  evolutions  presentant  des  m^anismes  de  meme  nature  que  ceux  pris  en  compie  par 
OC5 

-  Le  couplage  a  la  Structure  d’Accucil  Systeme. 

d)  Produits  realises  a  I'aide  de  DLAO 

Chaque  specification  est  une  suite  de  definitions  d’objets  et  de  leurs  attributs  avec  les  relations  entre 
les  objets.  Elle  fait  I'objet  d'un  document  dont  la  nature  a  pu  ^tre  definie  par  I’utilisateur. 

<>.2.2.2.  SAP  (Specification  Assistee  par  Ordinateur) 

a)  Obiei  de  SAP 

L'outil  SAP  aide  a  constituer  la  specification  qui  prend  en  compie  les  exigences  vis  a  vis  du  materiel 
et  celles  specifiques  au  logiciel  d'un  equipement  (algorithme  d’une  loi  de  pilotage  ou  de  guidage,  par 
exemplc). 

b)  Concepts  manipules  par  SAP 

La  specification  est  constituee  par  un  ensemble  de  planches,  repertoriees  enlivreset  chapitres. 

Les  objets  sont  principaiement  saisis  et  manipuies  a  I'aide  d'un  langage  graphique  dont  I’ediieur  fan 
appel  a  des  bibliotheques  de  symboles  graphiques,  adaptws  aux  types  d'appL 'ation, 

c)  Fonctionnalites  de  SAP 


Comme  le  montre  la  figure  3,  les  principales  fonctionnalites  de  SAP  sont  les  suivantes  : 

-  La  saisie  interactive  des  specifications  a  I’aide  d'un  ^iteur  graphique  et  de  bibliotheques  de 
symboles, 

-  La  gestion  d'espaces  de  travail  pour  les  concepteurs,  independants  de  I'espace  officiel  contenant  les 
etats  consultables  des  specifications, 

-  Les  possibilites  de  modification,  de  suppression  et  d'adjoriction  de  planches  dans  une 
specification  avec  une  gestion  associee  des  conflits 

-  Le  controle  de  coherence  au  niveau  d'une  planche  de  specification 

-  Le  controle  de  coherence  au  niveau  de  I'ensemble  de  la  specification 

-  La  gestion  des  evolutions,  devant  mettre  en  oeuvre  des  mecanismes  analogues  a  ccux  des  autres 
outils  de  I'Atelier  Systeme 

-  La  capabiJite  d'etre  interface  avec  la  Structure  d’Accueil  Systeme. 
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d)  Produits  reaJises  a  I'aide  de  SAP 

Une  edition  de  I'ensemble  de  planches  coherentes  pour  former  une  specification  constitue  le  document 
(graphique  ei  textuel  relatif  a  une  version  de  la  specification  concerns). 

4.2.3.  La  Structure  d'Accueil  Systeme 

a)  Qbjet  de  la  Structure  d'Accueil  Systeme 

C’est  le  support  informatique  qui  permet  au  systemier  de  gerer  : 

-  la  iogique  de  developpement  d‘un  systeme* 

-  les  rapports  entre  tous  les  intervenants  dans  un  programme  d'avionique, 

-  les  demandes  d'evolution  concernant  un  systeme. 

II  s'agit  en  effet  ; 

-  de  maintenir  I'ensemble  de  ia  documentation  de  specification  a  jour  et  de  gerer  sa  diffusion, 

-  de  pouvoir  identifier  a  partir  du  niveau  le  plus  global  du  systeme  I'impact  d'une  demande  d'evolution, 

-  de  garantir  en  permanence  la  coherence  de  la  definition  d'un  systeme, 

-  d'offrir  aux  responsables  de  projet  la  possibilite  de  consulter  les  differents  etats  de  developpement  de 
I’ensemble  des  entiles  ayant  part  a  la  definition  d'un  systeme, 

-  de  gerer  les  procedures  d'acceptation  relatives  aux  demandes  d'evolution  et  les  repercussions  sur  les 
produits  constituant  les  specifications. 

b)  Concepts  manipules  par  la  Structure  d'Accueil  Systeme 

La  Structure  d'Accueil  Systeme  s’appuie  sur  une  base  de  donnees  et  rassemble  des  mecanismes  qui  ont 
pour  but  : 

-  d'assurer  la  coherence  des  informations  connues  dans  I'Atelier  Systeme,  dans  le  cadre  d'un  programme 
d’avionique, 

-  de  gerer  les  acres  et  les  aciivites  liees  aux  outils  de  I'Atelier  Systeme, 

-  d'assurer  la  bonne  execution  des  fonctions  de  communication  entre  outils  de  I'Atelier  Systeme,  vers 
I'Atelier  Logiciel,  vers  I'exterieur  du  Systeme  de  Developpement  d'Avionique. 


c)  Fonctionnalites  dc  la  Structure  d'Accueil  Systeme 

La  figure  4  montre  les  grandes  fonctions  de  la  Structure  d'Accueil  Systeme  et  les  hens  qui  existent  entre 
elies. 

-  L'initialisation  de  projet  : 

Elle  permet  I'installation  d’un  projet  dans  I'Atelier  Systeme,  quant  aux  previsions  relatives  au  plan  de 
developpement  du  projet  et  a  la  configuration  necessaire  pour  utiliser  I'Atelier  Systi^me  pour  ie  proiet. 

-  L'administrateur  : 

11  a  pour  missions  principales  d'interpreter  les  commandos  et  les  requetes  des  utilisateurs  et  de  gerer 
les  acces. 

-  Le  suivi  des  evolutions  : 

Cette  fonction  concerne  la  gestion  des  fiches  d'evolution  et  implemente  les  exigences  qui  ont  ete 
enoncees  plus  haut. 

-  La  gestion  de  configuration  ; 

Cette  fonction  a  pour  role  de  gerer  les  etats  du  developpement  d'un  systeme  et  les  transitions  entre 
ces  etats. 

-  Les  activites  liees  aux  outils  : 

I'ensemble  des  fonctionnalites  couvertes  ici  concerne  tous  les  aspect',  de  liaisons  entre  la  Structure 
d'Accueil  Systeme  et  les  outils  de  I'Atelier  Systeme. 

-  La  composition  de  documents  : 

Elle  permet  de  erwr  des  documents  complets  a  partir  des  "produits"  elementaires  contenus  dans  les 
bases  de  donnees  propres  aux  outils  et  d'adapter  leur  structure  aux  exigences  de  chaqje  programme. 


-  En  corrolaire  la  gestion  de  la  diffusion  : 
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Elie  s'occupe  de  la  tenue  a  jour  des  iisies  de  diffusion  des  documents  de  specification  et  de  la 
memorisation  des  documents  diffuses  dans  le  cadre  d'un  programme  et  en  particuiier  en  ce  qui 
concerne  leur  version  et  lews  destinataires. 

d)  Produits  realises  a  l*aide  de  la  Structure  d'Accueil  Systeme 

A  la  demande  des  responsables  de  projet,  des  etats  : 

-  d'avancement  du  projet 

-  des  specifications 

-  de  la  diffusion  des  documents 

-  des  fiches  d'evolution  prises  ei.  compte,  en  etude, 
peuvent  etre  generes. 

4.3.  L*impfantation  informatlque  de  l*Ateiier  Svsteme 

Un  souci  tres  vif  de  portabifite  a  prevalu  dans  les  choix  informatiques  de  base  faits  pour  la  mise  en  oeuvre  de 
I’Atelier  Systeme. 

Les  outils  logiciels  qui  ont  ete  d^rits  sont  affectes  a  des  stations  de  travail,  fonctionnant  sous  le  svsteme 
d’expioitation  UNIX.  Pour  I'implementation  des  outils,  I’emploi  du  langage  C  est  favorise  toutes  les  fois  oii 
cela  est  possible.  Les  premiers  choix  de  stations  de  travail  sont  APOLLO  et  IBM  6150. 

La  Structure  d'Accueil  Systeme  est  implant^  sur  une  machine  hote,  connect^  aux  stations  de  travail.  Les 
premiers  choix  sont  VAX  (VMS),  connecte  a  APOLLO  et  IBM  (VM/CMS)  connecte  a  IBM  6150. 

Comme  cela  a  ete  explique  plus  haut,  les  outils,  d’une  part,  la  structure  d’accueii  d’autre  part  gerent  les 
donnees  qui  leur  sont  p.'opres,  dans  des  bases  de  donnas  independantes  et  sans  redondance.  Oans  cc  cadre-la. 
et  toujours  dans  un  souci  de  portabilite,  d'ouverture  et  d’homogeneite,  le  systeme  de  gestion  de  bases  de 
donnees  relationnel  ORACLE  a  ete  retenu  pour  tous  les  outils  et  pour  la  structure  d'accueil  et  cela,  bien  sur, 
pour  les  deux  versions  de  materiel  informatique. 


5  -  L’ATELIER  LOGICIEL 


Comme  cela  a  ete  explique  dans  I’expose  deia  cue  en  reference,  les  mdustriels  partenaircs  dc  I'otude  ITI.  qvii 
par  ailleurs  possedaicnt  en  propre  des  elements  d’Atelier  Logicie)  ont  pns  communement  cons(  icnce  quo  le 
developpement  du  logiciei  a  vocation  embarqu^  est  une  aciivite  tres  liee  a  la  caparite  creative  des  porsonnes. 
Cette  capacite,  si  elle  n’est  pas  canalisee  par  des  mcthodcs  et  des  outils  ngoureux.  peut  conduire  a  des 
resultats  qui  ne  sont  pas  compatibles  avec  les  objectifs  d'unc  entrcpnse  induslnelle  on  matiere  de  inaitrise  des 
deiais  et  de  la  qualite. 

En  ce  qui  concerne  les  travaux  de  conception,  realisation  et  tests  des  logiciels,  des  outils  nortibreux  et 
performants  sont  deja  en  exploitation  au  scin  des  differents  mdustriels  tncn^bres  d’lTl. 

Pour  ces  domaines,  le  principal  souci  Hps  travaux  est  done  de  proposer  un  '''semble  coherent,  possedant  des 
hens  etroits  aver  I'Atelier  Systeme.  et  disponiblc  pour  rensembl**  de  la  communaute  aeronautique,  re  qui  a 
conduit  a  la  definition  d'un  Atelier  Logiciel  pour  lequel  sont  presentes  successivement  ci-dessous  : 

•  Les  fonctionnalites  attendues 

«  Les  raracteristiques  des  outils  au  regard  du  cycle  dc  vie  logiciel 

•  La  mise  cn  oeuvre. 


5.1.  Les  fonctionnaJites  attendues  de  I'Atciier  Logiciel 

Les  principales  fonctionnalites  attendues  d'un  Atelier  Logiciel  sont  les  suivantes  : 

a)  II  doit  ttre  le  support  efficacc  d'unc  methodologie  rigoureusc  de  developpement  de  logiciels. 

En  effet,  les  caractenstiques  des  logiciels  intervenant  dans  les  systemes  avioniques  sont  tres  pointues. 
Ellcs  necossitent  I'adoption  et  la  mise  en  oeuvre  de  methodes  dc  definition,  dc  conception,  de  realisation 
et  de  tests  stricts  et  fiables. 

Les  logiciels  de  ce  type  participent  a  la  socuriie  des  sytemos  auxquels  ils  contribuent  lls  comportent  en 
particuiier  la  mise  en  oeuvre  de  traitements  "temps  reel''. 

b)  Pour  repondre  aux  besoir*’  de  divers  programmes  d'avionique,  qui  peuvent  se  derouler  en  meme  temps, 
I'Atelier  Logimel  doit  etre  capable  d'accepter  des  environnements  de  programmation  relatifs  a  differents 
langages. 

c)  L'lntegration  des  modules  logiciels  et  les  tests  relatifs  a  leur  validation  doivent  etre  farilues  par  des 
moyens  de  test,  coni^us  cn  liaison  directe  avec  les  autres  elements  de  ''Atelier  Logiciel  qui  sont  utilise^ 
pour  generer  les  entrees  de  ces  phases  ultimes  de  la  realisation  des  logiciels. 
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d)  L'Atelier  Logiciei  a  egalement  pour  mission  d'offrir  des  moyens  permettant  d'assurer  la  gestion  de 
configuration  des  logiciels  en  developpement  et  de  preparer  les  livraisons  de  logiciels. 

ll  s'agit  de  gerer  les  etats  du  developpement  a  divers  instants  du  cycle  de  vie  du  logiciel  et  les  transitions 
entre  ces  etats.  Les  fonctions  a  remplir  sent  done  principalemeni  I'identification  de  la  configuration  des 
logiciels  et  le  maintien  de  son  integrite  par  une  gestion  efficace  de  I'application  des  modifications 
logicieiles  initios  au  niveau  global  du  systeme  et  transmises  depuis  I' Atelier  Systeme. 

e)  Une  interface  "Homme-machine"  conviviale  et  adapts  aux  utilisateurs  de  I'Atel.er  (concepteurs  de 
logiciels,  programmeurs  ...)  est  requise  pour  rendre  pleinement  efficaces  Ics  services  de  I'Atelier  Loginel. 

f)  L'Atelier  Logiciel  doit  pouvoir  etre  interface  a  I'Atelier  Systeme  selon  les  criteres  qui  seront  expliciies 
plus  loin  dans  le  paragraphe  consacre  aux  communications  entre  Atelier  Sysieme  et  Atelier  Logiciel. 


5.2.  Caracteristiques  des  outils  au  reftard  du  cycle  de  vie  logiciel 

Trois  etapes  principales  peuvent  etre  distinguees  dans  le  cycle  de  realisation  d’un  logiciel,  a  partir  de  la 
fourniture  des  specifications. 

a)  Les  phases  de  definition  et  de  conception 

Les  activites  qui  y  sent  associees  sent  principalement  ; 

•  L'identification  des  fonctions  logicieiles  et  de  leurs  interfaces 

•  L’elaboration  de  la  structure  "temps  reel"  et  la  definition  des  mecanismes  associes 
«  La  definition  des  tests  do  validation 

•  L'analyse  informatique  du  (ogiciel  a  reahser. 

Des  outils  logiciels  specifiques  supportent  ces  activites  de  maniere  sequentielle. 

b)  La  phase  de  realisation  du  logiciel 

Les  activites  conduites  pendant  cette  phase  sent  les  suivantes  : 

'  le  codage 

'  la  production  d'executables 

-  les  tests  unitaires. 

Les  langages  de  programmation  embarquabics  retenus  sontdusde  haul  niveau. 

c)  Les  phases  d’integration  et  de  validation  du  logiciel 
Elies  mettent  en  oeuvre  les  type'  d'entils  suivan.s  : 

'  Editcurs  de  liens 

-  Generateurs  d'application 

-  Outils  de  tests  statiquo  et  dynamique. 

5.3.  La  mise  en  oeuvre 

L'orientation  prise  en  matiere  d'Atelier  Logiciel  par  les  mdustriels  membres  du  groupe  ITl  esi  de  s'appuycr 
sur  les  realisations  de  I’atclier  LNTREPRISE  ellcs-memos  financoos  par  lo  Mmistere  fran(,ais  de  la  Defense  oi 
dc  participcr  aux  evolutions  dc  ret  atelier. 

Les  buts  d'ENTREPRlSE  dc  seconde  generation  sont  les  suivanis  : 

a)  L'atelier  doit  fournir  un  cadre  coherent  pour  le  developpement  d'applications  logicieiles  en  LTR3,  en 
langage  C  ou  en  Pascal,  en  ADA,  pouvant  inclure  des  parties  errites  en  assembleur. 

b)  L'atelier  doit  pouvoir  gerer  la  coherence  de  produits  tels  que  documents  de  definition  ou  de  ronreption, 
programmes  sources  ou  objets,  documentation  de  realisation,  applications  particUes  ou  completes, 
bibliotheques,  moniteurs,  programmes  ou  fichiers  de  tests.  ... 

c)  L'atelier  dolt  etre  dote  d'outils  assurant  une  plus  large  rouverture  du  (  vcle  de  vie  logiciel  que  ceux  de  la 
premiere  generation. 

d)  La  gestion  de  configuration  doit  vjser  I’extension  a  dc  nouveaux  objets  geres  au  sein  de  i'aielier  permet- 
rant  ; 

-  la  gestion  de  la  documentation 

-  le  controle  et  la  gestion  des  modifications  logicieiles. 
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e)  La  gestion  de  projet,  en  rapport  avec  la  base  de  dor^n^s  d*£NT  REPRISE,  sera  realtsee  par  un  outil 
permettant  de  planifier  les  projets  et  d'en  assurer  le  suivi  en  couts  et  delais. 

La  demarche  du  groupe  IT  I  vise  I'obtention  d'un  Atelier  Logictel  adapte  aux  activites  de  ses  membres, 
ayant  une  definition  coherente  avec  Tatelier  ENTREPRISE  de  seconde  generation  et  qui  pourrait  en 
constituer  un  surensembie  entierement  compatible.  Dans  ce  but,  I'accent  est  mis  particulierement  sur  les 
points  suivants  : 

-  La  definition  des  capabilites  de  communication  avec  I' Atelier  Systeme 

-  L'outil  de  definition  de  logiciel  qui  doit  pouvoir  exploiter  les  specifications  de  logiciels  venant  de 
I'Atelier  Systeme 

-  L'outillage  supportant  ies  phases  de  conception  globale  et  detaillee  de  logiciel  qui  doit  supporter  une 
methodologie  : 

•  Privilegiant  une  approche  descendante  structure 

•  manipulant  des  concepts  coherents  avec  ceux  utilises  pour  la  definition  du  logiciel 

•  preparant  de  maniere  correcte  rutUisaticnde  langages  de  programmation  de  haut  niveau 
t  formalisant  des  notions  de  programmation  structure. 

-  L'integration  dans  I'Atelief  Logiciel  d'un  outillage  ayant  pour  but  la  mise  au  pioint  et  le  test  dynamique 
des  logiciels. 

Les  princlpales  caracteristiques  demand^s  a  un  tel  outil  sent  les  suivantes  : 

•  La  formalisation  et  la  standardisation  des  operations  de  test 

•  L'automatisaiion  de  ces  operations  et  I'execution  de  tests  de  non-regression 

•  Le  test  en  temps  reel  et  la  non  perturbation  du  comportement  des  programmes  a  tester 
«  La  description  sous  forme  symbolique  des  controles 

•  L'independance  vis  a  vis  des  moyens  de  productiuii 
«  L'independance  vis  a  vis  des  machines  cibles 

-  Ld  rnise  en  oeuvre  d'une  gestion  de  configuration  prenant  en  (ornpte  tous  les  constituants  d'une 
application  logtrielic  donnee  et  tous  les  produits  qui  lour  sont  associes,  disposant  des  mecanisrnes 
convenables  pour  le  suivi  des  evolutions  logicicllcs. 

L'orientation  retenue  au  niveau  des  materiels  informatiqucs  dans  un  souo  de  portabilite  est  la  inise  a 
disposition  de  I'Atelier  Logiciel  sur  des  stations  de  travail  iravaillant  sous  le  systeme  d’exploitdtion  IMX. 
le  langagc  de  realisation  privilegic  otant  C. 

6  -  LES  COMMUNICATIONS  ENTRE  CES  ATELIERS 

Los  rchangos  nccessairos  entre  I'Atelier  Systeme  et  les  Ateliers  Logiciels  vitihses  dans  le  cadre  d'un  rnenic 
programme  avionique  sont  identifies  en  tenant  compte  du  partage  mdustnel  des  taches. 

De  maniere  globale,  on  pent  dire  que 

-  de  r  Atelier  Systeme  vers  un  Atelier  Logiciel 

transitent  ies  specifications  des  logiciels  a  realiser  et  les  demandes  de  modifications  a  appiiquer 

-  d'un  Atelier  Logiciel  vers  I’Atelier  Systeme 

transite  I'idcntification  dc  la  fourniture  logictelle  (configuration  du  logiciel  livre.  equipement  concerne  ...) 

Pour  realiser  des  communications  efficaces  : 

•  II  faut  qu'un  certain  nonibre  de  concepts  soit  commun  entre  ceux  manipules  par  les  outils  de  I'Atelier 
Systeme  pour  elaborer  les  specifications  des  logiriels,  et  reux  qui  sont  dans  les  Ateliers  Logiriels  pour 
effectuer  la  definition  proprement  dite  du  logiciel  et  I’idcntification  de  sa  configuration. 


II  est  necessaire  que  les  actions  d’lmportation  et  d'exportation  relatives  a  un  atelier  se  (assent  au  erasers 
dc  sa  structure  d'accucil,  dont  alors,  en  Px*rticulier  la  fonction  "gestion  de  la  diffusion”  doit  etre  aciivee 
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•  L'lmplefnentation  informatique  des  liaisons  entre  ateliers  comporte  trois  aspects  : 

a)  Les  procedures  de  communication 

Elies  soni  a  respecter  ngoureusemeni  au  rours  des  echanges  afin  de  maintentr  la  coherence  et  la 
securite  des  informations. 

b)  La  realisation  materielle 

Elle  depend  prlncipaiement  des  moyens  utilises  par  les  partenaires  du  programme  considere  et  aussi  de 
leur  situation  geographique  relative. 

c)  La  confidentialite 

Son  respecr  necessite  la  mise  en  oeuvre  des  moyens  et  de  procedures  specifiques. 


7  ~  CONCLUSION 


La  premiere  version  du  Systeme  de  Developpement  d’Aviomque  (Atelier  Systeme  et  Atelier  Logiriel)  va  etre 
utilisee  dans  les  prochains  programmes  aeronautiques  auxquels  prendront  part  les  industriels  de  la  <ommunauie 
avionique  fran^aise.  Ces  programmes  en  permcttront  ainsi  la  validation  en  grandeur  reelle. 

Compte  tenu  du  point  aciuel  d'avancemeni  des  travaux  de  mise  en  oeuvre,  lout  laisse  a  penser  que  les  rnovens 
resultant  repondront  aux  objectifs  iniiiaux. 

lls  constitueront  le  support  necessaire  pour  (ormaiiser  les  relations  entre  industriels  cooperants  dans  un 
programme  avionique  et  assurer  par  voie  de  consequence  une  meilleure  qualite  a  un  cout  mojndre  en  mettant  a 
profit  les  corripetcnces  et  experiences  acquises. 

L’abo'itissement  des  travaux  engages  constituera  un  point  de  depart. 

En  plus  des  evolutions  et  complements  inherents  a  tout  produit  logiciel,  le  souci  d’evolutivite  qui  a  guide  le 
choix  des  techniques  de  realisation  er.  faisant  du  Systeme  de  Developpement  d’Avionique  un  sysieitie  ouvert. 
permettra  ; 

•  L'introduction  d'autres  outils  couvrant  des  activjtes  complementaires  au  cours  du  cycle  de  developpcTnent. 
ou  repondant  a  des  contraintes  specifiques  d'un  utilisatcur 

•  L'utilisation  de  techniques  et  de  technologies  informatiques  nouvellcs,  telles  la  defmit.  m  et  la  rruse  er, 
oeuvre  de  systemes  experts 

Reference  I  :  "Systeme  avionique.  Methode  de  developpement  et  outils  inforn»atiq..eV’ 

(Philippe  LAROCHE-LEVY  -  AMD-BA.  FRANCE). 
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Author's  Reply 

1.  introduction  progressive  desoutils  aupres  dcs  utilisateurs  cst  facilite  par  ic  fan  que  lev  ouiiN  supporient  une  melhode 
dejii  appliquee  dans  ies  derniers  pr<'grammes.  Aussi.  apres  une  penodc  dc  formation,  les  utilisateurs  decouv  rent  Ics 
gams  attendus: 

•  Une  meilleure  c«>mmunication  cnire  Ics  intervenants  impliques: 

•  Une  aide  a  l’obtenti<m  de  specifications  de  qualite.  I'outil  stuilagcam  Ic  spccificatcur  dc  laches  repetitivcs  dc  eontrdic: 

•  F-l  principalcmeni.  unc  aide  au  mainiicn  a  jour. 
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ABSTRACT 


An  advanced,  computer  based  engineering  design  methodology  and  tool  set,  which 
enables  and  enhances  complex  system,  subsystem  and  component  design,  analysis, 
Integration  and  verif ication/validation  testing  -  in  an  operational  context  - 
is  described  here. 

Tile  burgeoning  threat  to  the  security  of  NATO  alliance  countries,  dramatic 
escalation  of  costs  and  protracted  schedules  associated  with  weapons  system 
acquisition,  from  concept  development  to  first  flight,  dictates  the 
Introduction  of  drastic  improvements  in  the  way  the  technical  community 
approaches  the  design  and  development  process.  Similar  improvement  must  be 
made  in  techniques  utilized  by  the  procuring  agencies.  Improved  methods  for 
assessing  the  technical  merit  of  proposed  problem  solutions  as  well  as 
subsequent  verification  of  compliance  with  procurement  design  specifications 
must  also  be  established. 

The  timely  evolution  of  enabling  technology  in  areas  of  high  speed  digital 
computers,  structured  software,  systems  design  methods,  sophisticated 
simulation  and  graphics  techniques  have  made  these  much  needed  improvements 
now  possible. 

Major  failings  of  predecessor  and  even  contemporary  approaches  to  the 
application  of  computer-based  simulation  in  the  design  process  lie  in: 

1)  relative  inflexibility  of  the  simulations,  2)  persistent  dedication  to 
effectiveness  analysis  as  an  end-product  rather  than  design  optimization, 

3)  lack  of  deterministic  assessment  in  favor  of  stochastic  methods, 

4)  Inadequate  and/or  esoteric  means  for  data  base  access  and  manipulation, land 

5)  awkward,  difficult  to  understand  and  use  output  data. 

However,  by  far  the  most  significant  drawback  of  existing  approaches  to 
design,  using  computer  based  simulation  tools,  is  that  they  fail  to  produce 
the  coherent  time-line  state  data  essential  to  complete  evaluation  of  the 
design  objects  (system/subsystem/component),  in  a  dynamic,  high  fidelity  and 
operational  context. 

When  fully  implemented,  functional  development  by  means  of  manipulation  of 
coherently  derived  time-line  state  data,  in  a  dynamic,  high  fidelity  and 
operational  context,  will  enable  concurrent,  fully  Integrated,  rapid 
prototyping  and  subsequent  detailed  design  synthesis  of  the  avionics,  vehicle, 
weapons  and  crew  systems  components  of  a  total  weapon  system. 

Having  once  put  in  place  the  described  methodology  and  tool-set,  opportunities 
for  exploitation  of  the  resulting  coherent  time-line  state  data  are  limitless, 
ranging  from  mission  effectiveness  analysis  and  detailed  design,  to  test  sets 
for  logistic  support  and  training  devices,  for  both  operations  and  maintenance 
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INTRODUCTION 


Central  to  our  ability  to  bring  the  current  protracted  development  cycle  back 
into  an  affordable  time  span  is  the  introduction  of  new  and  more  powerful 
development  tools  and  methods.  Figure  1  illustrates  our  current  posture  of 
around  twelve  (12)  years  from  COI  to  IOC.  This  is  nearly  three  (3)  times  that 
of  only  a  decade  or  so  ago. 

The  tremendous  challenge  precipitated  by  the  “hypothetical"  system 
requirements  illustrated  in  Figure  1  creates  a  virtual  log  jam  which  may  be 
portrayed  by  Figure  2.  Elevated  threat  levels  as  well  as  rapidly  evolving 
technology  creates  a  much  more  difficult  problem  to  solve  and  results  in 
solutions  featuring  extremely  complex  design,  development  and  test 
approaches.  The  end  result  is  envariably  protracted  schedules,  increased  cost 
and  uncertainty  in  performance  achievability. 

Contemporary  weapons  systems  development  approaches  will  not  meet  the 
challenge  of  the  1990's  and  needs  help.  A  structured,  formal  and 
operationally  relevant  approach  such  as  that  alluded  to  in  Figure  3  will  be 
required.  Traditional  approaches  fail  in  several  respects.  Firstly,  each 
phase  of  the  process  generally  employs  stand-alone,  unrelated  and 
operationally  non-relevant  tool  methods  and  procedures.  Secondly,  top  level 
as  well  as  flowed-down  requirements  are  generally  not  derived  in  a  dynamic 
operational  context.  This,  of  course,  makes  functional  thread  traceability 
virtually  impossible.  Figure  4  illustrates  this  traditional  approach. 

Advanced  avionics  systems  are  characterized  by  several  important  features 
which  bear  heavily  upon  the  need  for  "requirements"  to  be  developed  and 
maintained  (from  mission  level  to  the  lowest  level  IPO  and  chip)  in  a  dynamic 
operational  context.  First  of  all,  advanced  systems  typically  will  contain 
2  '  4  X  10^  higher  order  language  lines  of  code  (Ada),  This  infers  that 
many  of  the  functional  processes  here-to-fore  accomplished  in  hardware  are  now 
done  in  software.  Secondly,  processing  speeds  in  the  order  of  3  -  4  x  10^ 
complex  operations  per  second  (BOPS)  for  vector  processing  and  30  -  40  x  10*> 
instructions  per  second  (MIPS)  will  be  required.  Therefore,  not  only  are  most 
of  the  functional  processes  executed  in  a  physically  transparent  and 
inaccessible  media,  but  they  are  running  at  incredibly  high  speeds. 

Functional  performance  capability  of  a  given  system  process,  therefore,  can 
only  be  assessed  when  operating  in  that  high-speed,  inter-active  domain. 

Figure  5  itemizes  some  of  the  more  important  steps  to  be  taken. 


CONCEPT 


A  need  is  suggested  by  the  foregoing  for  a  methodology  to  "capture"  the 
"design  state"  of  each  and  every  design  variaole  involved  in  either  the  object 
of  the  design  process  or  the  "environment"  to  which  the  design  object  is 
subjected.  Figure  6  depicts  the  process  of  coherently  cAnacting  the  "state" 
data.  The  “state"  data  is  referred  to  as  "time-line"  state  data  because  it  is 
developed  and  produced  in  response  to  some  pre-determined  time-ordered 
sequence  of  events. 

To  those  who  have  labored  rigorously  over  the  past  several  years  on  advanced 
weapons  system  projects  the  need  for  "coherency"  is, self-evident.  Quite 
simply  stated,  in  an  advanced  weapons  system  (avionics  suite  specifically  in 
this  case)  all  components,  i.e.,  sensors,  busses,  computers,  etc.,  are 
utilized  at  all  times  when  they  can  spatially,  spectrally  or  temporally 
contribute  to  a  functional  process.  Moreover,  the  components  must 
continuously  be  assessed  for  availability  as  well.  Data  fusion  (Radar/IR/CNI) 
is  one  example.  Dynamic  processor  reconfiguration  is  another. 
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Figure  6  illustrates  the  occasion  where  “ownship“  sensors  are  characterized 
and  via  digital  simulation  exposed  to  a  threat  environment  under  control  of  a 
simulation  executive  program.  The  response  of  "ownship"  sensors  in  terms  of 
their  "design  state"  is  collected  and  utilized  for  subsequent  input  into  the 
core  architecture  computer,  software  and  sensor  design  process.  As  shown,  the 
product  of  the  simulation  design  process  is  subsequently  compared  to  actual 
hardware  and  software  designs  for  requirements  validity.  Control  of  the 
design  characteristics  of  "ownship"  as  well  as  cooperative  Blue  assets  and  Red 
threats  is  accomplished  from  the  center  block  shown  in  Figure  6  as  “Tool 
Management  and  Control".  A  non-real  time,  large  scale  version  (80,000  lines 
of  Fortran  77  code  hosted  on  two  micro-VAX)  has  been  developed  and  is  now  in 
operational  use. 

Significant  also  is  the  fact  that  individual  "functional  threads"  can  be 
traced  and  controlled  by  this  method  as  indicated  by  Figure  6. 

Implied  but  not  implemented  in  this  version  is  the  integration  of  both  the 
Crew  Station  interfaces  and  Flight  Controls  interfaces  (dashed  lines  at  top 
and  bottom  of  figure). 

This  early,  non-real  time  coherent  concept  forms  the  basis  for  the  major 
emphasis  of  this  paper  discussed  in  the  following  sections. 


APPROACH 


It  is  not  possible  to  overstate  the  need  for  four  (4)  important  factors  to  be 
embraced  by  any  successful  advanced  development  process: 

1)  Real-time  operational  context  design  and  assessment. 

2)  Coherency  between  all  design  objects. 

3)  Careful  sensitivity  assessment  between  all  design  objects. 

4)  Computer  based. 

The  object  of  this  paper  is  a  tool  called  "Coherent  Design  Evaluation 
Simulation  (CODES)".  Top-level  features  of  the  tool  are  illustrated  by  Figure 
7. 

Figure  8  illustrates  the  concept  that  a  common  environmental  simulation  which 
always  accounts  for  the  evaluation  and  response  of  all  weapon  system  design 
objects  can  be  implemented  to  achieve  total  weapons  system  functional  and 
physical  development  (including  real-time  man-in-the-loop  simulation  and  pilot 
vehicle  interface/situation  awareness  simulations).  Figure  8  is  slightly 
misleading  in  that  all  of  the  models  (avionics,  vehicle,  flight  controls)  are 
actually  within  "CODES"  but  are  drawn  as  shown  to  illustrate  their 
inter-actions. 

When  viewed  in  the  context  of  the  weapons  system  development  process,  as  shown 
in  Figure  9,  the  CODES  tool  can  be  used  as  the  driver  or  data  source  for  all 
development  phases  from  mission  effectiveness  analysis  through  maintenance  and 
training.  All  the  necessary  functional  requirements  are  present  at  all 
levels,  through  all  mission  phases. 


ARCHITECTURE 


The  software  design  of  the  COOES  computer-based  engineering  methodology 
employs  a  high  level  of  modularity  in  a  hierarchial  format  for  efficient 
upgrade,  modification  and  maintenance.  This  architecture  provides  for 
efficient  incorporation  of  modules  representing  various  objects  and 
sub-objects  to  varying  degrees  of  detail.  Typical  of  the  objects  in  CODES  are 
airframes,  radars,  IR  sensors,  EW,  missiles,  guns,  pilot,  etc.  The  object 
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oriented  approach  allows  for  accoimodatlng  variable  levels  of  detail  within 
the  methodology  consistent  with  the  objectives  of  the  engineering  design 
analysis.  For  example,  radar  system  design  analysis  would  use  high  levels  of 
detail  in  those  models.  While  other  factors  such  as  IRSTS,  might  be  handled 
by  first  order  models.  Simulation  fidelity  versus  run-time  is  an  important 
consideration  in  virtually  all  applications  of  these  types  of  methodologies. 
While  the  technical  purist  desires  models,  algorithm,  and  simulations  to  the 
Nth  degree  in  detail,  the  pragmatist  understands  too  well  the  impact  upon 
computer  run-time  resource  requirements,  and  ultimately  the  utility  of  the 
methodology.  The  methodology  must  be  efficient  to  be  useful  and  run-time  is 
important.  Obviously  this  factor  becomes  even  more  important  when  coupled  to 
crew  design  synthesis  tools  and  simulators  in  particular.  The  impact  of 
inefficiency  can  be  very  expensive  through  the  need  for  extensive 
computational  facilities  to  support  required  simulator  performance.  Hence  a 
balanced  level-of-detail/fidelity  versus  resources  trade-off  is  required  if 
costs  are  going  to  be  maintained  within  a  manageable  level.  To  partially 
achieve  this,  the  methodology  must  be  immersed  within  a  "low-fidelity" 
context,  to  allow  efficient  utilization  of  “high  fidelity"  modules  applied  to 
the  specific  objective  of  study.  This  means  putting  the  fidelity  where  it 
does  the  most  good  while  using  lower  fidelity  in  areas  which  exhibit  only 
second  order  effects. 

Factors  of  a  user  friendly  nature  play  a  key  role  in  the  versatility  of  the 
CODES  methodology.  This  aspect  is  of  singular  importance  as  it  provides 
efficient  operation,  training,  and  siroulation/methodology  management  with 
minimal  operator  expertise  and  effort.  This  aspect  has  been  particularly 
important  in  the  past  as  the  operation  and  maintenance  of  a  large  number  of 
data  items  in  itself  consumes  extensive  manpower  resources.  This 
consideration  requires  the  application  of  modern  software  tools  such  as 
relational  data  bases,  interactive  menus,  configuration  agents,  and  a  host  of 
output  display  graphics  which  provide  for  flexible  presentation  of  coherent 
time-line  data.  These  latter  elements,  coupled  with  hard  copy/presentation 
formats  of  data  and  graphics  provide  for  maximum  communication  and  transmittal 
of  ideas,  concepts,  data,  and  trends,  with  minimal  effort  free  effort. 

The  overall  hierarchy  of  COOES  is  shown  in  Figure  10.  It  consists  of  an 
executive  for  interfacing  the  engineering  software  with  the  applications 
tools,  i.e.,  crew  and  avionics  design  synthesis  tools.  The  executive  controls 
the  data  base  management  systems  (DBMS),  simulation  models,  and  the  post 
processors  to  provide  formatted  outputs  to  the  applications. 

Simulation  Executive 


The  Simulation  Executive  provides  the  overall  control  for  organizing, 
synthesizing,  operating,  and  interfacing  the  computer  methodology  with  various 
applications.  It  provides  the  mechanism  for  setting  up  the  problem  on  an 
interactive  basis  with  a  minimal  amount  of  manual  overhead.  It  also  assures 
that  relevant  modules  communicate  properly,  synchronously  developing  the 
outputs  to  assure  coherent  time-line  data.  The  executive  routes  these  data 
for  processing,  graphic  output  and/or  simulator  interface. 

Data  Base  Management  System  (DBMS) 

The  Data  Base  Management  System  (DBMS)  provides  the  where-with-al 1  to  maintain 
and  manipulate  large  amounts  of  weapon  system  design  parameters.  The  COOES 
methodology  is  predicated  upon  evaluation  of  various  system  design  options  in 
an  operational  context.  As  such,  not  only  are  the  engineering  design 
parameters  of  interest  stored  in  the  DBMS,  but  so  are  parameters  of  all 
ancillary  operational  factors  interacting  with  the  methodology.  As  threat 
perception  plays  a  key  role,  the  organic  variability  and  changing  assessment 
of  their  design  and  performance  factors  must  be  easily  updated  in  either 
manual  or  automatic  (via  data  tape)  fashion.  Periodic  update  of  threat 
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parameters  occurs  approximately  every  six  months.  Nominally  10,000  data  items 
are  required  to  define  th  performance  parameters  of  the  threat  air  defense 
system  excluding  geographic  coordinates.  The  maintenance  of  these  data  is  a 
critical  task  if  relevant  timely  results  are  to  be  obtained. 

In  CODES,  threat  and  engineering  design  parameters  are  maintained  in  a 
‘bonded"  data  base  with  multiple  password  access.  For  a  specific  analysis/ 
simulator  run,  these  data  are  accessed  and  transferred  to  a  run  file  where 
they  may  be  used  as  is,  or  varied  parametrically  for  purposes  of  engineering 
performance  and  sensitivity  analysis.  The  DBHS  configuration  agent  archives 
each  runs  data  results  so  that  future  reconstruction  of  the  analysis  is 
possible.  The  flexibility  of  interactively  modifying  the  run-file  allows 
analytical  exploration  of  various  design  alternatives,  operations  and  tactics 
as  well  as  long  term  assessment  of  threat  growth  implications. 

Simulation  Models 


The  simulation  models  in  COOES  develop  the  operation  and  performance  of  all 
the  major  elements  of  the  weapon  system  and  interacting  environment  for  the 
conditions  specified.  These  object-oriented  models  are  of  sufficient  detail 
to  permit  sub-system  design  trades  to  optimize  weapon  system  performance. 

These  models  represent  all  major  avionic  systems  on  the  aircraft  including 
radar,  IRSTS,  EW,  IONIA,  etc.  as  well  as  the  environmental  factors  that 
interact  with  weapon  system  operations,  i.e.,  threat  radars,  missiles,  C^, 

GCI,  clutter,  visibility,  etc.  The  executive  links  together  these  elements  to 
construct  somewhat  generically  the  scenarios  to  be  analyzed.  For  example, 
interactive  menus  provide  prompts  for  selecting  the  number  and  type  of  red 
aircraft,  blue  aircraft,  engagement  geometry,  scenario,  key  sub-systems  of 
interest,  tactics,  operations,  etc.  The  executive  retrieves  the  relevant 
design  parameters  from  the  DBMS  to  convert  the  linked  generic  models  to 
represent  a  specific  engagement  scenario.  Fully  specified,  the  simulation  can 
be  run  over  a  broad  set  of  engagement  parameters  to  determine  outcome. 
Obviously,  the  parameters  can  be  exercised  over  excursions  to  identify 
sensitivity  of  system  design  to  performance. 

Post-Processor 


The  Post  Processor  performs  data  bookkeeping  and  develops  graphic  outputs  for 
each  engagement.  Here  the  coherent  time-line  data  generated  in  the  system 
models  and  engagements  is  processed  to  develop  measures  of  effectiveness. 

This  output  may  vary  from  time-lines  of  design  parameters,  variables,  and  key 
events,  i.e.,  target  detection,  missile  launch,  aircraft  state,  inventory 
draw-down;  to  generation  of  three-dimensional  situational  and  synthetic 
cockpit  displays  (HUD'S  C-SCOPE,  etc.).  This  output  is  further  processed  and 
formatted  to  Interface  with  the  crew  station  synthesis  tool.  In  this 
application,  it  provides  the  basic  input  for  driving  the  various  elements  of 
the  simulator. 


MAN  HACHINE/DESIGN  TOOL  INTERFACE 


The  Man  Machine/Design  Tool  provides  the  interactive  computer  aided 
engineering  design  work  station  for  purposes  of  performing  system  design 
trades  in  an  operational  context.  With  this  methodology,  the  system  engineer 
can  synthesize  an  aircraft  configuration  including  observables,  offensive/ 
defensive  avionics,  weapons  tactics,  performance,  etc.,  and  fly  it  through  a 
hostile  air  defense  environment.  Furthermore,  menu  prompts  provide  the  design 
engineer  a  training  mechanism  as  well  as  continuous  "help"  functions  to  assist 
in  data  set-up,  manipulation  and  engineering  analysis.  This  methodology 
provides  the  system  engineer  the  first  evaluations  as  to  the  performance  and 
shortcoming  of  his  aircraft  design  from  an  avionics  point  of  view.  He  can 
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observe  via  situation  and  synthetic  cockpit  displays  how  the  engagement  Is 
progressing  and  what  are  the  key  performance  drivers  for  maximizing  system 
design.  By  varying  design  parameters.  Improvements  in  aircraft  performance 
can  be  easily  observed. 

Approaches  to  aircraft  system  design  have  been  exercised  in  a  fragmented 
manner  in  the  past.  Each  major  sub-system  designer  has  developed  their 
requirements  somewhat  Independently  and  In  a  piecemeal  fashion.  For  example, 
the  radar  engineer  would  address  the  operational  scenario  differently  than  the 
weapons  designer.  This  was  often  a  laborious  and  time  consuming  process  with 
full  integration  not  occurring  until  the  equipment  was  installed. 

Furthermore,  the  required  coherent  t1me-l1ne  data  has  been  burled  in  a  vast 
amount  of  analysis  and  test  data  with  different  assumptions  and  baselines  used 
by  the  sub-systems  developer.  This  made  Interpretation  of  results  in  an 
integrated  fashion  difficult  If  not  Impossible. 

CODES  utilizes  the  efficiencies  of  computer  aided  engineering  methodology  by 
providing  an  automated  means  of  setting  up  and  solving  problems  in  a  truly 
integrated  fashion.  The  total  aircraft  configuration  is  synthesized  in  the 
computer,  exercised  in  an  operational  context,  optimized  as  an  integrated 
design,  and  evaluated  over  a  broad  set  of  operational  conditions.  These 
evaluations  can  be  conducted  for  both  near-  and  far-term  requirements  to 
address  an  evolving  advancing  threat  capability.  The  result  is  a  set  of 
coherent  time-line  data  which  provides  state  information  on  all  major  elements 
of  the  problem.  This  factor  is  key  to  developing  optimized  solutions  for 
tomorrow's  advanced  aircraft  system  designs  in  a  totally  integrated  manner. 


REAL  TIME  MAN-IN-THE-LOOP  INTEGRATION 


COOES  provides  the  core  software  for  generating  the  reaction  a  hostile  air 
defense  system  would  undertake  in  response  to  an  impending  penetration.  As 
such  COOES  Provides  the  methodology  for  driving  a  man-in-the-loop  simulator, 
for  simulating  penetration  of  the  hostile  airspace. 

Utilization  of  the  core  CODES  software  optimizes  the  utility  of  the  tool  and 
provides  an  efficient  transition  from  engineering  analysis  to  pi lot-in-the- 
loop  simulations.  It  is  also  important  from  the  aspect  of  software 
maintenance  and  data  base  management.  Further  it  not  only  allows  efficient 
transition  of  variables  from  one  weapon  system  design  to  another  in  the  work 
station  as  well  as  the  simulation,  but  easily  accommodates  changing  threats 
and  different  operational  scenarios.  The  work  station  and  simulator  can  be 
easily  “reprogrammed"  by  simply  calling  up  the  relevant  menus  and  changing  the 
appropriate  engineering  design  parameters. 

For  example,  suppose  it  is  desirable  to  optimize  the  radar  requirements  versus 
an  IR  sensor.  The  engineering  work  station  would  be  used  to  first  perform 
system  design  trades  between  these  sensors  to  identify  performance  overlaps 
and  options.  Then  the  sub-systems  design  modules  for  each  would  be  exercised 
to  verify  the  feasibility  of  designs  to  meet  performance  requirements.  Once 
design  baselines  are  established,  engagements  would  be  run  inter-actively  on 
the  work  station,  and  then  the  design  data  used  to  drive  the  simulator  so  that 
the  vehicle  can  be  evaluated  with  the  pilot-in-the-loop. 

HARDWARE/SOFTWARE 


The  utility  of  CODES  can  be  extended  even  further  for  digital  hardware-in-the 
loop  hot  bench  testing.  An  extension  of  CODES  generates  a  bus  of  digital 
pulses  as  would  be  generated  by  various  avionics  sensors  and  processed  by  an 
ASA  or  PAVE  PILLAR  onboard  the  aircraft.  As  CODES  generates  coherent  time¬ 
line  data  on  all  participants  or  the  engagement,  this  data  can  be  utilized  to 
control  "digital  signal  generators"  and  provide  the  proper  signal  bus  format 
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to  the  digital  processors.  This  feature  allows  the  hardware  to  be  tested  over 
a  broad  range  of  test  scenarios  for  validation  and  verification  of  processor 
performance. 

Digital  processors  can  also  be  tested  by  tying  In  with  cockpit  displays  and 
Indicators.  Hence,  the  pi  lot-1 n-the-loop  provides  for  effective  evaluation  of 
processor  design  through  simulated  flight  runs  in  the  simulator,  with  this 
configuration,  data  bus  traffic,  response  format  and  timing  can  be  tested  and 
evaluated. 


EFFECTIVENESS  ANALYSIS 


A  fundamental  role  of  CODES  Is  mission  effectiveness  analysis.  CODES  provides 
the  operations  analysis  the  tool  to  efficiently  evaluate  vehicle  mission 
effectiveness  over  a  broad  range  of  operational  conditions  and  scenarios.  The 
scope  of  COOES  provides  a  full  complement  of  Threats,  c3  environments, 
operations,  tactics,  etc.  to  allow  synthesis  of  scenarios  representing  vast 
major  operations.  With  COOES,  the  transition  from  work  station,  to  simulator, 
to  hardware-ln-the-loop,  to  mission  analysis  represents  a  relatively  straight¬ 
forward  process  accomplished  with  menus  and  pointers  through  a  totally  Inter¬ 
active  process.  Hence  the  aircraft  configuration  can  be  optimized  on  the 
engineering  work  station,  tested  by  a  pllot-ln-the-loop  simulation,  tested 
with  digital  processors-ln-the-loop  and  ultimately  exercised  over  a  broad  set 
of  operational  scenarios. 

The  utility  of  CODES  in  this  respect  Is  even  broader  as  it  provides  a  quick 
and  efficient  means  of  testing  aircraft  performance  specifications  against 
mission  requirements.  Further  It  allows  Integrated  mission  assessment  from 
close  a1r  support  to  deep  interdiction.  Identifying  new  or  overlapping  roles 
of  advanced  aircraft  designs.  Here  the  true  value  resides  to  the  modern 
aircraft  designer.  For  he  must  design  his  aircraft  In  a  totally  integrated 
manner  to  successfully  compete  and  accomplish  today's  challenging  requirements. 


6ENERAL  CAPABILITIES 


Figure  11  1s  typical  of  the  CODES  implementation  process. 

Proceeding  from  a  set  of  requirements  specified  to  the  CODES  tool  via  one  of 
the  many  tools  now  under  development,  the  design  console  shown  is  utilized  to 
construct  the  mission  scenarios  and  tactics  statements  appropriate  to  the 
missions  as  well  as  statements  of  the  problem  to  be  used  as  a  basis  for 
evaluating  performance  In  terms  of  measures  of  effectiveness  (MOEs). 

The  real-time  mission  scenarios  are  now  executable,  under  simulation  executive 
control,  so  that  the  design  approach  effectiveness  can  be  observed  and 
optimized.  Figure  12  further  Illustrates  Important  operational  features  of 
the  COOES  tool.  Capabilities  illustrated  are  real-time  dynamic  intervention 
capability  of  the  operator,  availability  of  time-line  state  data  for  on-line 
or  off-line  use  by  associated  computer  based  analysis  tools  and  on-line 
performance  assessment  of  design  performance.  Some  of  the  more  salient 
features  of  COOES  Including  why  it  Is  unique,  are  listed  in  Figures  13-(a) 
through  (e). 

Probably  the  most  significant  breakthrough  presented  by  the  CODES  concept  is 
the  Integration  of  the  actual  design  proc'ss  with  real-time  man-1 n-the-loop 
simulation.  Through  this  Integration  process  the  designer  can  observe 
on-line,  Inter-actively  and  dynamically  the  effects  of  changes  In  the  state  of 
design  variables.  Hore  Importantly,  the  effects  of  simultaneously  altering 
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the  design  of  several  design  variables  can  be  observed  for  impact  upon  total 
weapon  system  performance. 

The  COOES  tool  will  evolve  through  several  levels  ranging  from  all-digital 
simulation  to  Incorporation  of  actual  hardware  and  software.  Figure  15 
Illustrates  CODES  Level  1  (all  digital)  with  the  heavy  arrows  indicating 
points  of  primary  operator  control.  Figure  16  shows  a  heavy  darkened  line 
around  the  “Signal  Processor  Hardware"  indicating  incorporation  of  actual 
hardware  or  a  hardware  emulator.  Figure  17  similarly  illustrates 
incorporation  of  actual  "Data  Processor  Hardware"  (this  infers,  of  course,  the 
actual  operational  flight  programs  would  be  operating).  Finally,  Figure  18 
illustrates  the  Integration  of  CODES  with  a  real-time,  man-in-the-loop 
simulation.  Important  to  note  that  the  CODES  “Level"  is  neither  indicative  of 
time  phasing  nor  is  it  homogenous  as  sequenced.  For  example,  real-time,  man- 
in-the-loop  simulation  integration  prior  to  completion  of  many  other  CODES 
design  features  is  planned  in  the  earliest  phases. 

One  of  the  more  important  characteristics  of  the  common  concept,  in  addition 
to  providing  high-fidelity  rapid  prototyping  capability  at  the  systems, 
sub-systems  or  component  level,  is  its  software  reconfigurability.  As 
illustrated  in  Figure  19,  for  instance,  the  CODES  tool  is  rapidly 
reconf igurable  to  address  a  wide  variety  of  weapon  system  requirements  through 
simple  construction  of  data  files,  scenarios  and  unique  algorithms. 

Additional  capabilities  planned  for  the  CODES  tool  include  automatic  software 
code  generation  and  validation  as  well  as  A1  algorithm  development. 

SUMMARY  AND  CONCLUSIONS 


Protracted  development  schedules  and  escalating  costs  can  be,  at  least  in 
large  measure,  contained  through  utilization  of  advanced  methods  and  tools. 
COOES  represents  but  one  offering  of  the  type  of  tools  necessary  to  do  the  job 
for  reasons  identified  in  Figure  20.  The  methodology  must  be  pervasive 
throughout  the  many  company  disciplines  (procurement,  manufacturing,  human 
resources,  finance)  for  the  development  process  to  be  truly  speeded-up.  Many 
companies  are  well  on  their  way  in  most  areas  except  the  design  areas 
addressed  by  this  paper. 

The  Impact  of  technological  credibility  upon  social  acceptance  of  defense 
projects  becomes  larger  each  year.  For  programs  vital  to  our  collective 
defense  posture  to  be  accepted  requires  high  levels  of  technical  credibility 
and  fiscal  responsibility.  Only  then  will  we  again  widen  the  narrowing  gap 
between  our  alliance  and  the  burgeoning  threat. 
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The  Development  Challenge 
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Help  Must  Come  in  the  Form  of  — 

•  New  coherent  methodologies  for 

—  Requirements  analysis 
—  Design  synthesis 
—  Design  verification/validation 
—  Integration  and  test 

•  Methodologies  wrapped  around  computer  based  tools 

•  Automated,  computer  based  project  management  and  control 

•  Reduced  levels  of  hi-tec  staff 

•  Training  programs  to  upgrade  staff 

•  Organizational  re-alignments 

•  Insight  into  requirements  for  long  lead  time  capital  investment 
to  meet  the  challenge  of  the  1990’s  and  beyond 
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engineering  tool  to  enable  and  enhance 

Design  analysis  and  rapid  prototyping 

Dynamic  hi  fidelity  real  time  man-in-the-loop 
simulations 

Hardware-software  system  Integration 
“in  the  dynamic  environment” 

Complete  system  design,  development 
and  integration  capability 


(U) 


FIGURE  7 
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Coherent  Design  Evaluation 
Simulation  Concept 
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FIGURE  8 
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Coherent  Design  Evaluation 
Simulation  Concept 
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CODES  Functional  Hierarchy 


1  COOES  1 

DATA  BASE  MANAGEMENT 
SYSTEM 

SIMULATION  SUPPORT  EXECUTIVE 
(RUN- time  AND  INTERRUPT  CONTROL) 

ENOINEERINO  DtATA 
PROCES$INGA>ECtSK>N 
EXECUTIVE 

UPCMTE 


MISSILES 


SCENARIOS 


OTHER  CMM 


RUN  FILE 
CREATION 


RUN-TME 

FILE 

(VERSIONS) 
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AIR  BATTLE  | 

INTEGRATED 

AIR-TO- 

SURFACE 

RADAR 


ICMA 


C2 


air-to-air 

J 

M 

AIR-TO- 

SCENARIO 

n 

9wnrM^f; 

SCENARIO 

tr  u 


MEWS 


PILOT 


OUN 


AIRFRAME 


ENVIRONMENT 
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QRAPHICS 


ANALYSIS 

POST- 

PROCESSOR 


SYNTHESIZED 

DISPLAYS 


MONITOR 

LIST1NQS 
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CODES  Process 


(U) 


System  Design  Tool 
Operation  Overview 


•  ONE-ON-ONE 

•  ONE-ON4IANY 

•  MANY-ON-MANY 


(U) 


RGURE  12 
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What  Makes  Codes  Unique? 

•  Integrated  end-to-end  penetrator/air  defense  engagement  simulation 

•  Fully  stand  alone  and  menu  driven 

•  Turn-key  operation,  user-friendly  interface 

•  Automated  data  management  of  thousands  of  unique  input  parameters 

•  Modeling  of  all  major  avionics  subsystems 

•  Automated  model  adjustment  to  selected  scope  of  simulation 

—  Air  battle 
—  Air-to-surface 
—  Integrated 
—  One-on-one 
—  One-on-many 
—  Many-on-many 

(U)  figure  13a 
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What  Makes  Codes  Unique? 
(Continued) 

•  User  interaction  with  simulation 

—  Interrupt  and  display  of  simulation  state 
—  Parameter  adjustment/optimization  during  simulation 
—  Tactical  decision  making 

•  Custom  graphic  display 

—  Pilot  displays 
—  Situation  displays 

•  Automated  analysis  tools 

—  Data  reduction 
^  Design  effectiveness  measures 
—  Graphical  representations 


(U) 


FIGURE  t3a  (CONT  O] 
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Simulation  Executive  Module  Scope 


•  Menu  driven 

•  Variable  I/O  and  data  recording 

•  Interrupt  scheduling 

—  Time 
—  Event 

•  Interrupt  handling/manual  decision  logic 

—  View  pilot  displays 
—  Modify  data 

—  Perform  engineering  calculations 
—  Plot  scenario 
—  Make  tactical  decisions 


(U)  FIGURE  13b 

(U) 

Simulation  Executive  Module  Scope 
(Continued) 

•  Coordination  of  players/scope  of  simulation 

—  Air-battle 
—  Air-to-surface 
—  Integrated 
—  One-on-one 
—  One-on-many 
—  Many-on-many 

•  Error  checking  and  error  handling 

•  Interrupt  logging/data  modification  logging 

•  Event  listings 


(U) 


FIGURE  13b  (CONT  0) 
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System  Models  Scope 


•  Airframe 

—  One  or  many 
—  Blue  and  red 

•  Avionics 

—  IRSTS 
—  ICNIA 
—  HR 
—  INEWS 
—  Al  radar 

•  Missile 

—  One  or  many 
—  Blue  and  red 
—  IR,  semiactive,  command 
—  Ground  and  air  launched 


•  Gun 

—  AAA 

—  One  or  many 

•  Threat  radar 

—  One  or  many 
—  Networked 

—  Airborne  and  ground  based 

•  C3  network 

—  Blue  and  red 

•  Environment 

—  Terrain 
—  Atmospherics 
—  Visibility 
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FIGURE  13c 
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Data  Base  Manager  Module  Scope 


•  Menu  driven 

•  Automated  input  and  maintenance  of  data 

•  Data  dispiay  options 

•  Two  level  data  base 

—  Data  file  data  base  —  system  data 
Airframe  parameters 
Missile  parameters 
Gun  parameters 
ADS  site  laydown 

C3  network  Types  of 

IRST  parameters  data  files 

ICNIA  parameters 
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FIGURE  13d 
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Data  Base  Manager  Module  Scope 
(Continued) 

•  Two  level  data  base  (continued) 

—  Input  file  data  base  —  engagement  specs 
Which  aircraft  ) 

Which  weapons 
Which  avionics 
Initial  conditions 
Environment 

•  Error  checking  and  error  handling 

•  File  protection  with  passwords 


(U)  FIGURE  13d  (CONT’D) 
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Post-Processor/Analysis  Module 

•  Menu  driven 

•  Error  checking  and  error  handling 

•  Data  displays 

—  Threat  laydown  and  fiightpaths 
—  Aircraft  signatures 
—  Site  masking 

•  Simulation  output  displays 

—  Detection  contours  (range  vs  angle) 

IR  and  radar  bumthrough 
With  and  without  jamming 

—  Vulnerability  contours  (range  vs  angle) 

With  and  without  maneuvers 
With  and  without  jamming 
With  and  without  expendables 


Self-protection 

effectiveness 


Integrated 
data  files 
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FIGURE  13e 
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Post-Processor/Analysis  Module 
(Continued) 

•  Simulation  output  displays  (continued) 

—  Pk  and  shot  opportunities 
—  Weapon  lethality 
—  RWR  signai  history/sensitivity 
—  Synthesi2ed  displays  (snapshot) 

•  Situation  plots 

•  Analytical  tools  (outputs) 

—  Sensor  data  correlation 
—  Signal/data  processor  loading  histories 
—  C3  network  loading  histories 
—  Exchange  ratios 
—  Weapon  delivery  accuracy 
—  Target  kill  probability 
—  Targets/penetrators  missed 


Mission 

success 
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FIGURE  13«  (CONT  D) 
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Dome/CODES  Integration 
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Avionics  System  Engineering 

Work  Station  Codes  Level  1  (All  Digital) 


(U) 

Signal  Processor  Hardware-in-Loop 

Codes  Level  2 


(U) 


FIGURE  1« 
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Digital  Processor  Hardware-in-ljOop 

Codes  Level  3 
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File  Based  -  Software  Reconfigurable 
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Summary  and  Conclusions 

•  An  engineering  methodology  which  allows  detailed  system, 
subsystem,  and  component  design  trade-offs  to  be  performed  and 
evaluated  in  an  operational  context  IS  MANDATORY,  DOES  NOT 
EXIST  but  IS  ACHIEVABLE! 

•  Protracted  development  cycles  are  assured  due  to 

—  Difficulty  in  achieving  advocacy  quickly 
—  Lack  of  confidence  in  ability  to  meet  performance  predictions 
—  Escalating  costs 

—  Inability  to  come  to  grips  with  evolving  technology 

•  Concerted  focus  on  methodology  and  tools  by  top  talent  with 
adequate  funding  will  quickly  resolve  (we  are  solving  design  issues 
too  times  more  complex  than  this  today) 

•  Codes  initial  configuration  characteristics  summary 

—  Hosted  on  two  (2)  Harris  1200  CPU’s  plus  ADI-100 
—  Approximately  100K  LOC  Fortran  77 
—  Interfaced  to  Evens  and  Southerland  CT-6  graphics  system 

(U) 
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Unclassified  Sumaary 

With  the  advent  of  the  Bus  System  and  the  possibility  for  using  multi-bus  structures, 
also  using  distributed  processing  and  an  overall  aodular  approach  to  partitioning 
Hardware  and  Software,  we  are  now  In  the  position  to  structure  future  Avionic  Systems 
differently  than  in  the  past.  A  straightforward  simple  decomposition  of  the  System 
into  "Black  Boxes",  which  perform  only  one  function,  will  belong  to  the  past. 

My  paper  will  deal  with  our  approach  to  structuring  modern  integrated, 
multifunctional  Avionic  Systems  and  its  Subsystems,  making  use  of  the  new 
technologies  emerging  for  aystem  hardware  and  also  using  the  new  methods  appearing 
for  system  design  and  management,  however  not  to  the  vastest  extent  possible  in  terms 
of  technologies  where  the  advent  of  VHSIC  and  system  structures  decomposing  down  to 
modules  would  of  course  impose  different  architectures  altogether. 

This  is  why  we  call  our  approach  to  system  architecture  "quasi-conventional" , 
because  it  still  provides  you  with  the  impression  of  "black  boxes".  But  this  is  not 
the  case  in  terms  of  the  past  time  definition. 

With  the  arising  new  technologies,  with  digitization  and  computerization,  our  future 
hardware  in  the  avionic  system  will  be  multifunctional .  i.e.  a  single  line- 
replaceable  item  LRI  (equipment)  will  perform  several  functions,  exhibit  several 
modes,  in  many  cases  serving  various  subsystems.  Nevertheless,  we  still  use  the  term 
subsystem,  actually  aiding  us  in  structuring  the  overall  system. 

The  first  part  of  my  paper  will  be  mostly  devoted  to  outline  the  guidelines  for 
designing  the  systems  architecture,  highlighting  the  various  subsystems  and  "multi"- 
functiona  required,  then  describing  the  system  architecture,  expedite  a  little  on  bus 
load  considerations  and  explain  the  concept  of  multifunctional  LRIs,  which  serve 
several  subsystems,  provide  for  several  functions. 


This  really  forms  a  highly 

integrated,  netted 

system  guided  by  the 

following 

dialectics: 

Several  Subsystems  serve 

one 

function 

or 

Several  LRls 

serve 

AND 

one 

function 

One  Subsystem 

provides 

for 

several 

functions 

or 

One  LBI 

provides 

for 

several 

functions 

Designing  such  a  system  In  terms  of  system  management,  system  architecture,  bus 
structure,  data  transfer  and  distributed  processing  will  take  a  lot  of  careful 
Investigations  also  looking  at  important  issues  like  bus  loading,  computer  time 
loading  and  redundancy  management  of  system  functions.  The  second  part  of  my  paper 
will  outline  these  special  aesign  considerations  on  bus  load  and  distributed 
processing  power.  It  will  also  highlight  our  modem  approach  to  a  highly  Integrated 
Test  system. 

In  order  to  handle  such  a  netted  system  and  to  manage  a  proper  "top-down"  system 
design,  a  structured  approach  using  co^uter-aided  tools  is  foreseen,  also  fcr 
documentation.  Only  with  a  data  basis,  which  is  established  right  in  beginning  of 
the  programme  and  which  is  continued  consistently  throughout  the  development  phase 
until  system  integration,  test  and  validation,  a  proper  control  can  be  exercised.  The 
system  decomposition  during  design  can  then  be  validated  during  integration,  using 
the  same  tool  and  same  data  base. 

Therefore,  the  third  part  of  my  paper  will  describe  how  to  handle,  manage  and  control 
such  a  complex,  netted  symtem  for  decomposition  "top-down"  as  well  as  integration 
"bottom-up",  test  and  validation,  using  computer-aided  tools.  In  the  absence  of  a 


proper  IPSE,  we  are  using  a  tool  called  CORE-EPOS,  whose  features  will  be  shortly 
described.  It  will  be  highlighted,  that  there  is  a  need  for  integration  of  a  test 
support  Environment.  At  present  the  tool  TUS  is  used  but  needs  further  development. 

In  conclusion  it  can  be  stated,  that  modern  technologies  available  completely  revise 
our  approach  to  system  design,  system  architectures  and  system  development/ 
management . 

The  hardware  is  dominated  by  the  advent  of  Multifunction  Sensors,  Computerization  and 
Digitisation  which  leads  to  the  Capability  of  Sensorfusion  and  multifunctional  use  of 
Avionic  items. 

The  software  is  dominated  by  multiprocessor  items  and  multi  media  data  transfer.  This 
leads  to  a  modular  design  of  software,  high  throughput  and  memory  and  fast  data 
transfer. 

And  the  System  Management  is  dominated  by  a  set  of  integrated,  computer  aided  tools, 
leading  to  a  proper,  consistent,  effective  control  of  all  system  life  cycle  phases. 
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OCVELOPPCPkCNr  GE5  SYSIElwES  AVKMQLES  COM>L£)« 

-o- 

CXPERIENCE  ISSLC  DCS  PROGRAMyCS  MLJTA»C5  FRANCAIS 


PAR 

ICA  AKTOME  COURSIMAIJ-T 

SERVICE  TEOMQUE 

DE5  PROGRAlxg^gS  AERONAUnOLES  >  FRANCE 


PREAlMeULC 

Les  nouvelies  generations  cfaeronefs  sent  equipees  de  systemes  dont  I'importance  et  les  coOts  ne  cessent 

de  crottre. 


Le  developpement  de  ces  systeme^  a  necessite  ia  mise  en  place  par  les  Services  Officiels  Frangais  de 

methodes  i 
e  cfanalyse  du  besoin 

•  de  conception  et  de  developpement  des  materiels 

•  de  production 

•  de  suivi 

•  cfevolution  de  la  definition  en  fonction  du  temps. 

Ces  methodes  ont  essentiellement  pour  but  efarriver  ^  : 

•  satisfaire  I'utilisateur  (en  I'occurence  les  Etats-Majors) 

•  en  respectant  les  deiais 

•  en  contrdlant  strictement  les  coOts 

Elies  sont  basees  sor  I'experience  des  developpements  anterieurs  et  sont  done  ameiiorees  h  chaque 
nouveau  programme. 

Les  paragraphes  qui  suivent  devetopr^^t  les  idees  conductrices  utilisees  lors  du  developpement  du 
MIRAGE  2000  et  de  l'ATL2  (ATLANTIQLC),  les  anorrialtes  constatees  et  les  ameliorations  susceptibles  d'etre 
apportees  dans  le  cadre  du  Programme  ACT  (RAF  ALE). 
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[  -  L'ANALYSE  OES  BESOMS 

Les  besoins  en  renouvellement  des  a^ronefs  sont  expriin^s  par  les  utilisateurs  en  fonction  de 
i'^volution  de  leur  pare  et  dea  utiliaations  potentielies. 

Lea  Evolutions  du  pare  sent  essentielleraent  dues  k  : 

a  la  durEe  de  vie 

•  I'attrition 

Les  utilisations  potentielles  varient  selon  : 

•  les  besoins  en  performancea  i 
m  longueur  de  piste 

K  facteur  de  charge  en  connbat 
a  capacitE  d'emport 

a  ... 

•  la  dEfinition  de  nouvelles  misaiona  : 
a  dEfense  aErienne 

a  supErioritE 

a  reconnaissance  trEs  haute  altitude 

a  ... 

•  la  prEvision  <futiUsation  dens  divers  types  de  conflit  : 
a  centre  Europe 

a  thEatres  extErieurs 
a  ... 

e  I'Evolution  des  armements  i 
a  missiles  stand  off 
a  armes  h  guidage  terminal 

a  ... 

e  I'Evolution  des  menaces  : 
a  radioElectriques 
a  infrarouges 

a  ... 

L'utilisateur  a  ainsi  la  possibilitE  tfexprimer  ses  besoins  gEnEraux,  qui  vont  permettre  de  dEmarrer  les 
travaux  prEliminaires  indispensables  h  la  bonne  apprEhension  des  besoins  rEels. 

U  faut  insister  sur  la  difficultE  de  la  tftche  efexpression  des  besoins.  L'Etat  Major  qui  dEfinit  ses 
besoiits  va  voir  sa  responsabilitE  engagEe  sur  un  nombre  (fannEes  trEs  important. 

II  faut  en  effet  rappeler  que  le  cycle  de  vie  (fun  programme  tfavion  s'Etend  sur  40  ans  comme  le 
montre  le  diagramme  ci-dessous. 


AmEES  AVKM 


•  Etudes  de 


a  base 

base 

preparatoires 

a  developpements 

developpements 

developpements 

a  experimentaux 

experimentaux 

experimentaux 

etudes  preparatoires 

a  etudes 

ler  vol  maquettes 

a  preparatoires 

- lancement - 

Experimentation  sur 
maquette 

a  ler  voi  proto 

phase  prototype 

••  ler  moteur  de  sdrie  • 

- 

a  ler  vol  du  ler  de  sdrie 

fin  de  mise  au 
point 


renovation 


Retrait  du  service  en  fonction  du  potentiel 


iivraison 

serie 

entretien 

majeur 
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2  •  OGNCEPTK3N  DE5  MATE3«CLS 

A  la  suite  de  I'analyse  et  de  ia  mise  en  forme  de  ces  besoins  gdn^raux,  va  commencer  le  travail  de 

conception. 

Oiverses  solutions  sont  g^n^raiement  capables  de  r^pondre  aux  besoins  et  la  premiere  difficult^ 
reside  dans  te  choix. 

Celui-ci  peutf  bien  sOr,  fttre  aidd  par  Texamen  attentif  de  solutions  utilis^es  dans  certains  pays  en 
avance  technologique,  mats  il  eat  souvent  n^cessaire  de  se  conforter  par  des  Etudes  de  base  et  d'effectuer  des 
ddveloppements  exploratoires.  Les  (Wvel(^ement8  exploratoires  peuvent  s'arr^ter  au  stade  "papier"  ou  conduire 
6  la  fabrication  de  maquettes. 

Le  schema  suivant  donne  un  exen^le  de  ctfroulement  (fun  ddveloppement  exploratoire  ayant  pour  but 
I'^tude  de  maquettes  avionnables  de  Radars  A^roport^s  de  combat  adrien  et  (fappui  sol  (RACAAS). 

Maquette  (fenregistrement  en  vol  de  signaux 
numdriques  regus  par  un  radar  en  moyenne 
et  basse  frequence  de  rdcurreoce 

e  analyse  du  moddle  de  clutter  de  sol 
a  analyse  des  signatures  de  cibles 
Isoldes  ou  non 
Odfinition 
Essais  en  vol 

Maquette  de  validation  des  innovations  pour 
radar  futur 

•  moyenne  frdqucnce  de  rdcurrcnce 
e  dmetteur  permettant  le  fonctionnement 
en  haute,  moyenne,  basse  frdquence  de 
rdcurrence 

e  traltement  du  signal 
e  multicibles 

a  affinage  doppler,  image  haute  rdsolution 
Odfinition 
Essais  en  vol 

Maquette  avec  balayage  dlectronique  un  plan 
Odfinition 
Essais  en  vol 

Ces  ddveloppements  exploratoires  peuvent  aussi  porter  sur  le  logiciel.  Ainsi,  pour  doter  la  communau- 
td  avionique  frangaise  (fun  Systdme  de  Odveloppement  (f  Avionique  (SDA),  adaptd  aux  besoins  de  ddveloppement 
des  logiciels  cfdquipementa  des  systdmes  embarquds,  il  a  dtd  ddci(^  (5e  lancer  le  ddveloppement  exploratoire  :  IT! 
(intdgration  du  traitement  de  I'information). 
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88  99 

Etude  g6n6rale  de  definition  des  besoins  en 
traitement  des  systemea  avioniquea  future 

Definition  gJobaie  du  SDA  "  ■  ■  -  ■  -  ■  — 

Definition  detailiea,  planification  '  — 

Developpement  cTune  maguette  probatoire 
de  la  structure  (faccueil, 

Developpement  das  outils  logiciets  " 


Enfin  ces  developpements  peuvant  etra  pousses  trfes  loin  comma  cala  a  ete  le  cas  avec  le 
demonstrateur  Rafale  (photo  page  6)«  dont  la  rdla  a  ete  de  prouver  : 

a  le  bieo'fonde  de  la  formula  aerodynamique 
a  las  qualites  da  commandas  de  vol  numeriques 
a  lea  possibilites  qu'apportent  les  structures  nouvelies 

a  ia  validite  du  concept  <ftnterface  homme/machine  qui  avail  ete  regarde  au  cours  (fun  developpement 
exploratoire  sur  I'organisation  das  postes  tfequtpage  (OPE)  (photos  page  6) 
a  siege  incline 

a  combine  de  pilotage  avec  tete  moyenne  collimatee 
a  collimateur  tete  haute  hologra^^ique 
a  manche  lateral 
a  ... 

3  -  PHASE  preparatgk; 

Les  etudes  de  base  et  developpements  exploratoires  ayant  permis  de  valider  des  solutions  technologic 
ques,  le  lancement  du  programme  peut  etre  prepare.  Les  principales  etapes  sont  : 

a  Etablissement  de  la  fiche  programme 
a  Specifications  preUminaires 

a  Etablissement  du  plan  de  developpement  technique 
a  Etablissement  du  plan  de  financen^nt 
e  Lancement 

La  fiche  programme  est  FexpressicKi  du  besoin  des  utilisateurs.  Tiree  des  besoins  gendraux  cites  plus 
haut,  elle  precise  les  points  les  plus  importants,  fixe  les  limites  du  produit  aussi  bien  vers  le  bas  (performances 
minimales  acceptableSt  que  vers  le  haut.  11  faut  necessairement  limiter  les  demandes  et  trouver  le  compromis 
capable  d'etre  realise  avec  les  budgets,  deiais,  materiels  disponibles. 

Par  example  les  Etats^Majors  aimeraient  souvent  disposer  (fun  avion  de  superiorite  aerienne  (grande 
vitesse,  rapport  poussee-poids  eieve,  grande  manoeuvrabilite)  et  cfun  avion  (fappui  tactique  (M  :  0,  9,  basse 
altitude,  capable  d'emports  multiples,  bien  protege  par  des  systemes  complexes  de  contremesures).  Ils  doivent  se 
contenter  cfun  avion  polyvalent  (le  compromis)  pour  des  raisons  (feconomie  de  moyens. 

Cette  fiche  programme,  purement  operationnelle,  sera  transformee  en  specifications  preiiminaires 
par  les  Services  Techniques  qui  y  ajouteront  les  performances  h  realiser. 
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4  -  OEVELOPPCIkCNr 

A  partir  des  sp^cificatioiib  Lechniques^  it  va  6tre  possible  cfentreprendre  i'analyse  du  d^veloppement 
et  en  particulier  celui  du  syst^me  cfarmes  qut  sera  d^tatU^  ci-apr^s. 

La  premiere  ^tape  consiste  h  effectuer  ('analyse  op^rationnelle  des  besoins  de  fagon  ^  determiner  les 
solutions  enviaageables  du  point  de  vue  : 

a  capteura 

•  traitement  et  analyse  du  signal 
a  interfaces  pilote 
a  interfaces  armaments 
a  enregistrement,  transmission 
a  bus 
a  ... 


Cette  analyse  eat  effectude  avec  la  participation  de  groupes  de  travail  constitues  par  les  principaux 
industrials  concernes  et  par  I'avionneur. 

Clle  aboutit  4  une  architecture  fonctiorv>eile  at  h  une  liste  cfequipements. 

Cette  architecture,  comme  le  montre  la  planche  (page  8)  peut  6tre  relativement  complexe. 

La  tdche  de  choix  de  I'architecture  et  des  dquipements  est  du  ressort  des  Services.  Cette  tdche  est 
souvent  compliqude  par  les  ndcessitds  de  repartition  entre  equipementiers  prenant  en  compte  des  elements  peu 
techniques  de  politique  industrielle,  en  particulier  pour  les  equipements  dont  le  developpement  et  la  mise  au 
point  sont  de  coOts  tellenient  eieves  et  ('acquisition  tfexperience  teliement  difficile  que  la  concurrence  n'existe 
pas  en  France. 

O'autre  pert,  I'evolution  des  techniques  vers  le  numdrique  conduisant  6  disposer  dans  cheque 
dquipement  cfun  calculdteur  qui,  par  nature,  salt  tiaiter  nombre  de  probl^mes  math^rnatiques  et  de  gestion,  il 
convient  de  valider  une  architecture  logtcielle  et  une  repartition  des  calculs  : 

e  diminuant  les  charges  bus 
e  minimisant  les  coOts  en  : 

a  evitant  les  duplications  de  calculateurs  sophistiques 
a  rdduisant  au  maximum  les  developpements  du  logiciel 

Enfin,  comma  cela  a  ddje  etd  dit,  le  syst^me  sera  utilise  pour  de  nombreuses  annees  pendant 
iesquelles  les  evolutions  technologiques  sercKtt  continuelles.  II  est  du  ressort  des  Services  de  verifier  que 
I'architecture  choisie  est  susceptible  de  developpements  ou  de  modifications,  sans  probiemes  majeurs. 

VJne  des  voies  ouvertes  consiste  ^  essayer  de  crder  une  standardisation  au  niveau  des  entrees/sorties 
des  equipements. 

Pour  cheque  function  du  Systeme  (fArmes,  il  faut  alors  definir  des  Specifications  Globales  qui 
concernent  I'ensembte  des  equipements  realisant  cette  fonction  et  qui  definissent  avec  beaucoup  de  precision  : 

a  I'objectif  de  la  forK:tion 
e  le  rdle  de  chacvm  des  equipements 
e  les  interfaces  homme/machine 
#  les  reconfigurations  en  cas  de  panne 
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Ce  document  sufftt  en  lui-m6me  pour  d^finir  la  fonction  ^l^mentaire  qui  est  achet^e  par  les  Services. 

Bien  que,  actuellement,  ceux-ci  entrent  plus  dans  le  detail,  i]  conviendrait,  pour  limiter  leur  charge 
de  travail  et  surtout  leur  dviter  de  rentrer  dons  des  details  d’j  niveau  du  sp^ciaiiste.  de  limiter  la  surveillance  des 
Services  d  I'^laboration  de  ces  Specifications  Globales. 

Afin  qu'iU  puiasent  engager  leur  responsabilite  6  ce  niveau,  il  est  necessaire  de  disposer  de  moyens  de 
verification  des  Specifications  Globales. 

Les  moyens  existent  deje  sous  la  forme  : 

•  outil  (faide  e  la  Specification  (OASIS)  (photo  page  10) 

•  simulateur  de  combat  du  Centre  Electronique  de  TArmement  (CELAR)  (photo  page  10) 
a  simulateur  du  Centre  cfEssaia  en  Vol  (flstres  (C.E.V.)  (photo  page  10) 

O'autres  moyens  informatiques  qui  pourraient  etre  plus  simples  de  mise  en  oeuvre  et  ifemploi  que  les  prdc^dents 
sent  envisageables. 

Ces  moyens  ckiivent  permettre  la  validation  et  done  donner  une  r^ponse  trfes  tOt  aprfes  I'^dition  des 
.jpfacii'icui.iuits.  En  effet  une  rdponae  tardive  peut  donner  I'effet  contraire,  la  suite  du  d^veloppement  s’etant 
poursuivi,  les  rdsultats  issus  des  outils  conduisent  d  des  propositions  de  modification  avec  les  incidences  sur  les 
prix,  ddlais  et  en  gdndral  bon  ddroulement  du  programme  que  I'on  imagine. 

Apr^s  validation  des  Specifications  Globales  il  serait  envisageable  de  voir  les  Services  acheter  une 
fonction  validde  sans  participer  de  fagon  ddtalllde  k  la  suite  du  d^veloppement  et  en  intervenant  uniquement 
pour  la  reception  officielle.  Cet  achat  pourrait  fttre  forfaitaire,  les  prix  incluant  de  base  une  provision  pour 
correction  de  malfagons  ^ventuelles. 

Seutes  les  modifications  de  Specifications  Globales  resteraient  sous  contrdie  des  Services.  Ces 
modifications  justifides  devraient  etre  peu  nombreuses  si  un  consensus  etait  obtenu  au  cours  de  la  validation 
entre  les  pilotes  charges  de  la  mise  au  point  (pilotes  constructeurs,  pilotes  du  Centre  cfEssais  en  Vol  (C.E.V.), 
pilote  du  Centre  cfExperimentation  de  I'Armee  de  I'Air  (CEAM))  et  les  pilotes  operationnels.  Dans  ce  cas  les  vols 
cfessais  devraient  cesser  cTdtre  des  vols  cte  mise  au  point  des  Specifications  Globales  pour  devenir  des  vols  de 
verification  finale  de  la  Specification,  ce  qui  conduirait  b  reduire  leur  nombre  done  leur  coOt.  Le  droit  b  I'erreur 
due  b  des  phenombnes  non  accessibles  en  simulation  (par  exemple  :  defectuosite  des  capteurs,  modifications  des 
caracteristiques  dues  b  des  influences  extbrieures)  donneraient  seules  lieu  b  des  modifications  justifiees. 

Le  developpement  se  poursuit  au  niveau  equipement  et  logiciels  par  I'eiaboration  de  Specifications 

detainees. 


Les  equipements  sont  developpes  : 

e  soit  sous  la  responsabilite  de  I'Etat  qui  en  assure  aussi  I'integration  et  le  montage  :  materiel  A 
e  salt  sous  la  responsabilite  des  Services  avec  integration  par  la  Coordination  Industrielle  composee  des 
Industriels  majeurs  impliques  dar>s  le  developpement  et  de  I'avionneur  ;  materiel  B 
•  soit  directement  sous  le  responsabilite  de  TAviomeur  :  materiel  C 

La  notion  de  Coordination  Industrielle  permet  (fassurer  la  coherence  temporelle  et  materielle  du 
developpement  des  equipements  et  logiciels.  Elle  pose  par  contre  le  problbme  de  la  concurrence  industrielle  et  de 
la  non-divulgation  de  I'experience.  L'avionneur,  moins  implique  dans  la  concurrence  que  les  equipementiers,  sert 
cfagent  de  liaison.  La  Coordination  Industrielle  fait  I'objet  ifun  contrat  separe. 
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Le  d^veloppement  des  mat^rtels  de  ia  cat^gorie  B  peut  poser  plusieurs  probi^mes  : 

a  non  specificity  du  produit  qui  ne  pourra  etre  adapte  que  par  modifications  soit  internes,  soit  de  la  chatne 
fonctionnelle 

•  developpement  asynchrone 

•  manque  de  moyens  des  Services  pour  assurer  le  devetoppement  cf^quipements  complexes 

Les  materials  B  font  l'ob)et  de  Clauses  Techniques  (fintegration  sous  la  responsabilite  de  I'avtonneur. 

L'evolution  normale  semble  fitre  une  diminution  des  developpements  B  au  profit  des  C. 

Le  developpement  des  functions  se  termine  par  contrdle  sur  un  banc  cfintegration  dnnt  le  but  est 
de  valider  les  specifications  globales  d  travers  les  equipements  reels. 

Avant  d'etre  montes  sur  les  barKS,  les  equipements  doivent  subir  une  recette  materielle  et  logicielle 
permettant  d'eiiminer  urte  majorite  de  ddfauts.  (photo  page  12) 

Pour  cela  il  est  necessaire  que  les  equipementiers  puissent  disposer  (fun  outil  general  de  simulation  de 
I'environnement  permettant  cfabord  la  mise  au  point  puis  donnant  e  la  coordination  industrielle  ou  aux  Services, 
les  moyens  de  recette  en  usine. 

Cette  methode  devrait  aussi  permettre  de  reduire  les  evolutions  en  phase  de  developpement 
actuellement  gdrees  par  les  comites  locaux  de  modification  du  materiel  (CLM)  ou  les  comites  de  modification  du 
logiciel  (CML).  Ces  comites  sont  souvent  surcharges  par  le  nombre  evolutions,  traitees  sans  notion 
cfimportance  et  dont  le  bienfonde  n'est  pas  toujours  accessible  aux  Services  charges  de  les  gerer  du  point  de  vue 
temporel  et  financier. 

La  situation  actuelle  est  encore  acceptable  :  il  faut  en  effet  compter  ISOO  modifications  de  tous 
types  pour  un  avion  dont  le  logiciel  occupe  250K  ...  mais  peut->on  imaginer  la  gestion  necessaire  pour  un  logiciel 
de  2500K. 


Un  effort  considerable  est  necessaire,  ies  outils  ITI  doivent  aider  mais  les  outiis  generaux  de 
simulation  de  I'environnment  sont  certainement  necesseires  pour  pouvoir  trailer  de  tels  logiciels. 

Cnfin  cette  tdche,  comme  il  a  dejft  ete  dit,  pourrait  Stre  laissee  h  ia  Coordination  Industrielle,  les 
Services  se  reservant  les  cas  litigieux  et  ceux  touchant  les  Specifications  globales. 

Le  developpement  se  termine  apr^s  introduction  des  cternieres  modifications  issues  des  Essais  en  Vol. 


Le  passage  en  serie  ne  poserait  pas  de  difficultes  speciales  : 

a  si  tous  les  developpements  etaient  effectues  de  fagon  synchrone  et  la  mise  au  point  compietement  terminee 
a  si  les  methodes  (findustrialisation  n'avaient  pas  (finfluence  sur  les  performances  du  materiel 

Le  non  synchronisme  des  developpements,  I'introduction  de  demandes  nouvelles  par  rapport  aux 
Specifications  Globales  de  base  entratnent  des  retards  de  livraison  (jes  equipements  et  logiciels  qui  ont  oblige  e 
introduire  la  notion  de  standard. 
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Les  premiers  standards  sent  Iivr6s  avec  : 

•  des  fonctions  incomplfetes  ou  manquantes 

•  des  ^quipements  encore  6volutifs  qui  seronl  rattrap^s  par  mises  ^  hauteur  successives 

II  faut  insister  sur  le  fait  que,  ai  dans  un  premier  temps,  les  livraisons  partielles  satisfont  les 
utilisateurs,  elles  eminent  de  r^els  probi^mes  : 

•  de  qestion  J,.  pare  disponibie 

•  de  noria  des  ^quipements  en^rafnent  des  diminutions  de  ia  disponibiiit^  affectant  les  avions 

•  de  reprogrammation  des  calculateurs  et  de  d^veloppement  indispensable  ij'outils  de  rechargement 
a  de  mise  h  niveau  de  la  documentation 

a  de  disponibiliti^  des  moyens  de  test  et  de  maintenance,  eux  aussi  au  bon  standard 

A  ces  problfemes  techniques  sont  associ^s  ^videmment  des  problfemes  de  coOt.  La  solution  consiste  h 
contrfller  rhomoq^n6Tt6  des  cycles  et  ^  rtduire  au  maximum  le  nombre  de  standards.  L&  encore,  apparaTt  la 
ni^cessit^  du  contrftle  strict  des  Specifications  Globales  et  des  Evolutions  tardives  de  ces  spEcifications. 

A  titre  cfexemple,  le  diaqramme  ci-aprEs  donne  le  plan  de  dEveloppemenl  et  les  diffErents  standards 
<Ju  MIRAGE  2000. 


Standard  S 1 
Standard  S2 
Standard  S5 
Standard  SA 


sans  radar) 

(avec  radar  ROM) 
(avec  ECM  amEliorE) 
'avec  radar  RDP 


Le  standard  S2  est  celui  correspondanl  aux  spEcifications  qlobales  initiales  avec  radar  RDM  (Radar 
Ooppier  Multifonctioos) 

Les  mEthodes  (f Industrialisation  rEagissent  aussi  sur  le  passage  en  sEne  du  fail  : 

•  des  modifications  de  mEthodes  de  fabrication  : 

I  automatisation 

«  changement  de  technologie  el  en  particulier  de  composants 

•  des  modifications  de  tolErances 

•  des  changements  de  mEthode  de  recetle 

et  mftme  parfois  de  la  reprogrammation. 

Actuellemeol,  le  dEvcloppenr>€nt  sErie  s’accompagne  rfune  phase  de  mise  au  point  non  nEgligeable. 
Cette  phase  pourrait  Eire  rEduile  par  on  contrftle  plus  strict  de  la  production  de  sErie  par  rapport  k  la  production 
prototype.  Cela  demande  des  mEthodes,  des  moyens  et  du  personnel  irEs  qualifiE  en  nombre  suffisant. 


Cela  conduit  d  la  mise  en  place  de  la  geslion  "qualitE**. 
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6  -  LA  VE  EN  LmuSAnON,  LES  RENOVATUNS 

Les  diagrammes  ci-avanl  onl  montr6  que  le  ddbut  de  la  vie  de  I'avion  est  affect^e  par  des  restrictions 
op^rationnelles. 

Cette  vie  doit  dvoluer  en  fonctiun  des  denr^andes  nouveiles  des  utilisateurs. 

Celles-ci  peuvent  : 

■  soit  §tre  int^grdes  dans  le  syst^me  existant  par  un  processus  de  modification 

•  soit  dernander  une  6tude  complexe  renr^ettant  en  cause  le  systfeme  pr6c6demment  d^fini.  II  s'agit  alors  de 
renovation. 

Les  renovations  sont  des  ph^nomfenes  de  plus  en  plus  courants  du  fait  : 

•  de  la  rapiditd  de  revolution  de  la  technoiogie  des  capteurs  d'adaptation 

•  des  besoins  des  interfaces  homme/machine 

a  des  d^ veloppements  des  armements  et  des  menaces 

II  est  n^cessaire  datis  la  conception  des  systfemes  de  base  de  tenir  compte  dfrs  le  depart  des 
renovations  eventuelles  en  erdant  une  architecture  systdme  modulaire,  capable  efextensions,  de  reconfigurations 
et  travaillde  au  .iveau  des  entrdes  et  des  sorties  pour  accepter  des  fonctions  nouveiles. 

II  faut  outer  qu'une  telle  arnhit^-clufe  permettrait  aussi  en  utilisation  de  rdsoudre  certains  probldmes 
d'inldropdrabilitd  rencontrds  par  les  utilisateurs. 

Ce  souhait  peut  voir  le  jour,  dans  les  avions  modernes,  avec  la  banalisalion  des  dcrans  et  des 
comrnandes  mais  I'effort  de  standardisation  au  niveau  des  dquipements  doit  dire  poursuivi,  mdme  si  cela  oblige  d 
un  droit  de  regard  du  concepleur  do  systdme  sor  la  technoiogie  et  I’archi  tec  tore  interne  des  dquipements. 

cnNCLusnNS 

Ein  conclusion,  les  besoins  suivants  sont  mis  en  Evidence  : 

•  Ndcessitd  d'une  dtude  et  (fune  formalisation  prdcises  des  besoins  par  les  utilisateurs.  Ceci  conditionne  le  bon 
ddroulement  de  tout  le  programme 

•  Ndcessitd  d'une  analyse  fonctionnelle,  de  I’dcrilure,  de  la  validation  et  I'acceptation  de  Specifications  Giobales  des 
Fonctions.  Ces  specifications  giobales  constituent  le  niveau  tfengagement  entre  I'Etat  el  les  responsables  du 
developpemenl.  Cela  entraTne  le  besoio  en  outils  de  validation  et  d'acceptation  des  Specifications  rapides  et  sores 

•  Necessite  de  reduire  les  Evolutions  aussi  bien  en  cours  de  developpemenl  prototype  qu'au  moment  du  passage  en 
sene 

•  Necessite  efun  contrdie  constant  de  ia  qualite 

L'expenencc  acquise  sur  les  programmes  MIRAGE  2000  pourra  ainsi  Sire  reporiee  sur  TACT  (RAFALE) 
dans  le  but  cTaugmenter  la  qualite  et  les  possibilites  operationnelles  tout  en  reduisant  les  coOts. 


o 


-o  o- 
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DISCllSSION 


E. Daley,  UK 

Emphasis  was  placed  on  the  importance  of  agreed  specifications.  What  form  were  they  expressed  in.  and  w  hat 
procedures  were  used  to  check  them  at  the  specification  stage? 

Author's  Reply 

The  specifications  were  expressed  in  the  form  of  documents.  The  serifieation  procedures  w  ere  those  described  vn  the 
middle  of  the  paper,  e.s.sentially,  piloted  simulations  as  reaJi.stic  as  possible. 


W.R.Frled,  US 

W’ould  you  please  describe  the  'vpe  of  communication,  navigation,  and  radar  equipment  implemented  on  the  Mirage 
2001)  (e.g..  HF.  VHF.  UHF  radio:  voice;  and  data)? 

Author's  Reply 

Tiie  Mirage  2000  is  very  flexible  and  can  receive  on  several  system  variants  with  different  types  of  radar:  impulse 
floppier  radar  (Thomson-CSF),  multimode  floppier  radar  (Thomson-CSF).  and  Anlilope  radar  (FSD),  Navigation 
depends  on  an  inertial  system  using  recovery  of  accrued  performance  in  the  case  of  Antilope  radar.  Basically  ,  there  are 
two  VHF  UHF  radiosand  a  transmission  system  for  interception  data  (teleadhesion).  lncrea.sed  protection  radios  are 
available  as  an  option. 


THE  FUTURE  MARITIME  RECONNAISSANCE  AIRCRAFT  AS  PART  OF  AN  INTEGRATED  MARITIME 

BATTLEnELD  SYSTEM 

by 

D.Baldvvinson 
British  Aerospace  Pic 
Stockport,  Cheshire 
UK 

Although  operating  in  a  relatively  more  beni^  environment  than  a  fast  jet  combat  aircraft,  a  maritime  reconnaissance 
aircraft  is  a  complex  weapon  system  which  has  a  hi^y  integrated  set  of  subsystems.  Future  developments  in  the  ASW/ASVW 
scene  will  strengthen  the  requirement  for  the  weapon  system  to  be  a  fully  integrated  member  of  a  higher  order  system. 

A  move  to  carry  out  more  research  and  development  in  industry,  as  opposed  to  government  establishments,  has  helped  to 
involve  companies  in  higher  order  system  investigation.  This  paper  discusses  how  the  concept  of  this  greater  system  can  be 
investigated,  the  implications  for  the  platforms  involved  and  the  tools  which  could  assist  in  these  tasks. 
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This  symposium  was  designed  to  explore  how  today’s  system  designer  is  addressing  the  solution  to 
tomorrow's  avionics  systems  design. 

As  government  budgets  become  more  limited  for  the  research,  development,  testing  and 
production  of  military  aircraft  systems,  and  the  Warsaw  Pact  nations  continue  to  produce  all  types 
of  aircraft  in  greater  numbers,  the  NATO  nations  must  “re-look"  at  how  avionic  systems  arc 
developed.  In  general,  the  avionics  community  has  thought  of  avionic  architecture  as  the  integration 
of  a  collection,  of  “black  boxes”  (sensor,  navigation,  communication,  display,  etc.)  with  the  software 
allowing  for  the  communication  between  “black  boxes",  computers  and  man.  Normally,  the  system 
is  decomposed  into  manageable  parts  with  accurately  defined  interfaces.  With  the  advent  of  the 
VFISIC,  distributed  processing,  artificial  intelligence,  sensor  data  fusion,  etc.,  the  technologies  are 
blurring  the  clear  functional  allocation  defined  for  the  “black  box”.  Two  factors,  technology  and 
cost,  provide  both  an  opportunity  and  a  chaUenge  to  the  system  designers  to  design  future  avionics 
systems  whose  performance  degrades  gracefully,  is  reliable,  and  is  affordable. 
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